Download: Unterschied zwischen den Versionen
Mali (Diskussion | Beiträge) (→Direkter Zugriff auf das Git Repository) |
(→Direkter Zugriff auf das Git Repository) |
||
Zeile 8: | Zeile 8: | ||
Ist mittels | Ist mittels | ||
− | + | git clone git://git.brokenpipe.de/ethersex | |
oder wenn dies nicht geht: | oder wenn dies nicht geht: | ||
− | + | git clone http://git.ethersex.de/ | |
möglich. Eine bereits heruntergeladene Kopie des Repositories kann mittels | 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 [[Git|hier]]. | aktualisiert werden. Im Übrigen sei auf die einschlägige Literatur zu dem Quellcode-Verwaltungssystem Git verwiesen. Eine kurze Anleitung findet man auch [[Git|hier]]. |
Version vom 1. Mai 2009, 11:58 Uhr
Der Quellcode von Ethersex
Ethersex ist ein freies Softwareprojekt, das unter der GNU General Public License Version 2 steht. Die Firmware befindet sich derzeit in aktiver Entwicklung, wobei wir stets darauf achten, dass sie stehts (zumindest ziemlich) stabil funktioniert. Selbstverständlich ist dies nicht immer 100 %-ig möglich :-)
Der Quellcode wird in einem Git Repository gepflegt und kann von dort als aktueller Tarball heruntergeladen werden.
Direkter Zugriff auf das Git Repository
Ist mittels
git clone git://git.brokenpipe.de/ethersex
oder wenn dies nicht geht:
git clone http://git.ethersex.de/
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://git.brokenpipe.de/cgi-bin/gitweb.cgi?p=ethersex eingesehen werden.
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 beschiebenen Strategie gut im master branch untergebracht werden.