Download: Unterschied zwischen den Versionen
Stella (Diskussion | Beiträge) |
Habo (Diskussion | Beiträge) (→Direkter Zugriff auf das Git Repository) |
||
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 === |
Version vom 12. Juni 2010, 16:21 Uhr
Inhaltsverzeichnis
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.