Download: Unterschied zwischen den Versionen

Aus Ethersex_Wiki
Wechseln zu: Navigation, Suche
K
 
(2 dazwischenliegende Versionen von einem anderen Benutzer werden nicht angezeigt)
Zeile 21: Zeile 21:
  
 
Darüber hinaus kann der Quellcode im Internet unter http://github.com/ethersex/ethersex eingesehen werden.
 
Darüber hinaus kann der Quellcode im Internet unter http://github.com/ethersex/ethersex eingesehen werden.
 +
 +
==== Springe zum letzten als funktional markierten Version ====
 +
 +
Zunächst muss eine aktuelle Kopie von ethersex Repository vorhanden sein
 +
git pull
 +
 +
dann kann mittels "git checkout TAGNAME" zu der Marke gesprungen werden. Momentan gibt es nur eine Marke (Tag) namens "snapshot_compile_ok" die regelmäßig aktualisiert wird.
 +
 +
git checkout snapshot_compile_ok
  
 
=== Eigene Änderungen am Code mit GitHub ===
 
=== Eigene Änderungen am Code mit GitHub ===
Zeile 57: Zeile 66:
  
 
[[Category:Ethersex]]
 
[[Category:Ethersex]]
 +
[[Category:Git]]

Aktuelle Version vom 4. September 2011, 16:43 Uhr

Der Quellcode von Ethersex

Ethersex ist ein freies Softwareprojekt, das unter der GNU General Public License Version 3 steht. Die Firmware befindet sich derzeit in aktiver Entwicklung, wobei wir darauf achten, dass sie stets (zumindest ziemlich) stabil funktioniert. Selbstverständlich ist dies nicht immer 100 %-ig möglich :-)

Der Quellcode wird in einem Git Repository auf github.com gepflegt und kann von dort als aktueller Tarball heruntergeladen werden.

Direkter Zugriff auf das Git Repository

Ist mittels

git clone git://github.com/ethersex/ethersex.git

oder wenn dies nicht geht:

git clone http://github.com/ethersex/ethersex.git

möglich. Eine bereits heruntergeladene Kopie des Repositories kann mittels

git pull origin

aktualisiert werden. Im Übrigen sei auf die einschlägige Literatur zu dem Quellcode-Verwaltungssystem Git verwiesen. Eine kurze Anleitung findet man auch hier.

Darüber hinaus kann der Quellcode im Internet unter http://github.com/ethersex/ethersex eingesehen werden.

Springe zum letzten als funktional markierten Version

Zunächst muss eine aktuelle Kopie von ethersex Repository vorhanden sein

git pull

dann kann mittels "git checkout TAGNAME" zu der Marke gesprungen werden. Momentan gibt es nur eine Marke (Tag) namens "snapshot_compile_ok" die regelmäßig aktualisiert wird.

git checkout snapshot_compile_ok

Eigene Änderungen am Code mit GitHub

Will man änderungen an ethersex vornehmen, die wieder zurückfließen sollen kann man folgendes vorgehen wählen: Wenn man bei github angemeldet ist, kann man das ethersex Repository einfach durch einen klick auf "Fork" in seine github Sammlung kopieren. Dies ist dann das eigene ethersex Repository, dass man verändern kann wie man lustig ist. Von diesem persöhnlichen Repo kann man nun einfach sich lokal clonen

git clone git@github.com:username/ethersex.git

Dort macht man dann einfach seine commits und pushed es wieder nach github:

git push origin master

Wenn man nun bei github auf den 'Send Pull request' Button klickt, bekommen die ethersex maintainer ne Mail und können die änderungen leicht einpflegen. Dies ist fuer Betreuer des Repositories um Größenordnungen einfacher als mit patches zu hantieren.

Eigene Änderungen am Code in GIT

Für eigene Änderungen oder Ergänzungen empfiehlt es sich unter Umständen gleich einen eigenen Branch zu verwenden und nicht mit dem master Branch des lokalen Repositories zu arbeiten. Andernfalls können neue Changes aus dem Upstream Repository nicht mehr per Fast-Forward in den lokalen master Branch aufgenommen werden und "git pull origin" produziert jedes mal ein merge-commit.

Bei mir hat sich folgende Vorgehensweise bewährt:

git checkout -b local-mods

Eigene Änderungen können nun wie gewohnt mit "git commit" in diesen Branch aufgenommen werden. Der master Branch kann davon zunächst völlig unabhängig mit dem remote branch synchronisiert werden. Allerdings muss man ggf. den Branch explizit spezifizieren, falls wie im Beispiel noch "local-mods" Branch aktiv ist:

git pull origin master

Möchte man nun die neuen upstream changes auch in den eigenen topic branch (local-mods) übernehmen, kann das mit git-rebase erledigt werden, da man sich so ebenfalls den merge commit spart:

git checkout local-mods  # (Falls man gerade noch im master branch sein sollte )
git rebase master

Damit wird der topic branch local-mods auf das letzte commit des master branches rebased.

Sicher wäre es auch möglich Änderungen direkt am Master Branch durchzuführen, und diesen mittels rebase auf origin/master zu aktualisieren. Allerdings hat man dann nicht mehr die Möglichkeit zu differenzieren welche Changes nur lokale Experimente darstellen und welche später evtl. an das upstream repository zurückgegeben werden sollen. Diese können vermutlich auch bei der beschriebenen Strategie gut im master branch untergebracht werden.