Download: Unterschied zwischen den Versionen

Aus Ethersex_Wiki
Wechseln zu: Navigation, Suche
(Seite importiert.)
 
K
 
(12 dazwischenliegende Versionen von 9 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
 
== Der Quellcode von Ethersex ==
 
== 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 :-)
+
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 gepflegt und kann von dort als  
+
Der Quellcode wird in einem Git Repository auf [http://github.com github.com] gepflegt und kann von dort als  
[http://git.brokenpipe.de/cgi-bin/gitweb.cgi?p=ethersex;a=snapshot;h=master aktueller Tarball] heruntergeladen werden.
+
[http://github.com/ethersex/ethersex/tarball/master aktueller Tarball] heruntergeladen werden.
  
=== Direkter Zugriff auf das Git Repository ===
+
=== Direkter Zugriff auf das [[Git]] Repository ===
 
Ist mittels
 
Ist mittels
  
      git clone git://git.brokenpipe.de/ethersex
+
git clone git://github.com/ethersex/ethersex.git
  
 
oder wenn dies nicht geht:
 
oder wenn dies nicht geht:
  
      git clone http://git.ethersex.de/
+
git clone http://github.com/ethersex/ethersex.git
  
 
möglich.  Eine bereits heruntergeladene Kopie des Repositories kann mittels
 
möglich.  Eine bereits heruntergeladene Kopie des Repositories kann mittels
  
      git pull origin
+
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 HowToGit 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]].
  
Darüber hinaus kann der Quellcode im Internet unter http://git.brokenpipe.de/cgi-bin/gitweb.cgi?p=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 ===
 +
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 ===
 
=== Eigene Änderungen am Code in GIT ===
Zeile 29: Zeile 50:
 
Bei mir hat sich folgende Vorgehensweise bewährt:
 
Bei mir hat sich folgende Vorgehensweise bewährt:
  
<pre>
+
git checkout -b local-mods
  git checkout -b local-mods
 
</pre>
 
  
 
Eigene Änderungen können nun wie gewohnt mit &quot;git commit&quot; 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 &quot;local-mods&quot; Branch aktiv ist:
 
Eigene Änderungen können nun wie gewohnt mit &quot;git commit&quot; 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 &quot;local-mods&quot; Branch aktiv ist:
  
<pre>
+
git pull origin master
  git pull origin master
 
</pre>
 
  
 
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:
 
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:
  
<pre>
+
git checkout local-mods  # (Falls man gerade noch im master branch sein sollte )
  git checkout local-mods  # (Falls man gerade noch im master branch sein sollte )
+
git rebase master
  git rebase master
 
</pre>
 
  
 
Damit wird der topic branch local-mods auf das letzte commit des master branches rebased.
 
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.
+
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.
  
 
[[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.