Entwicklung/Git: Unterschied zwischen den Versionen

Clones mit SSH
(Clones mit SSH)
Zeile 29: Zeile 29:


Die Entwickler können in beliebigen Topologien organisiert werden und gleichen den Inhalt ihrer Repositories wechselseitig miteinander ab. Opencaching.de verwendet eine Art Sternstruktur, mit einem Haupt-Repository unter der Adresse  
Die Entwickler können in beliebigen Topologien organisiert werden und gleichen den Inhalt ihrer Repositories wechselseitig miteinander ab. Opencaching.de verwendet eine Art Sternstruktur, mit einem Haupt-Repository unter der Adresse  
* http://github.com/OpencachingDeutschland/oc-server3
* https://github.com/OpencachingDeutschland/oc-server3
   
   
Auf dieses Repo haben nur der Code Maintainer und seine Vertreter Schreibzugriff; alle anderen können nur lesen. Um auch Daten hochladen zu können, besitzt jeder Entwickler bei Github.com eine eigene Kopie - einen "Fork" - des Haupt-Repositories, z.B.  
Auf dieses Repo haben nur der Code Maintainer und seine Vertreter Schreibzugriff; alle anderen können nur lesen. Um auch Daten hochladen zu können, besitzt jeder Entwickler bei GitHub.com eine eigene Kopie - einen "Fork" - des Haupt-Repositories, z.B.  
* http://github.com/flopp/oc-server3
* https://github.com/flopp/oc-server3
   
   
Dein erster Schritt als Opencaching-Entwickler ist das Anlegen deines Forks. Dazu legst du dir auf [http://github.com Github] einen kostenlosen Account an, gehst auf http://github.com/OpencachingDeutschland/oc-server3 und klickst oben rechts auf "Fork".
Dein erster Schritt als Opencaching-Entwickler ist das Anlegen deines Forks. Dazu legst du dir auf [https://github.com GitHub] einen kostenlosen Account an, gehst auf https://github.com/OpencachingDeutschland/oc-server3 und klickst oben rechts auf "Fork".


Der zweite Schritt ist, dir eine lokale Kopie - einen "Klon" - deines Forks anzulegen. Wie du das im OC.de-Entwicklersystem machst, ist im Artikel [[Entwicklung/Entwicklersystem|Entwicklersystem]] beschrieben. Hier machen wir es einfach mal testweise - du kannst so viele Klone anlegen wie du möchtest, den Github-Repositories ist das egal:
Der zweite Schritt ist, dir eine lokale Kopie - einen "Klon" - deines Forks anzulegen. Wie du das im OC.de-Entwicklersystem machst, ist im Artikel [[Entwicklung/Entwicklersystem|Entwicklersystem]] beschrieben. Hier machen wir es einfach mal testweise - du kannst so viele Klone anlegen wie du möchtest, den GitHub-Repositories ist das egal:
  git clone git://github.com/<DeinBenutzername>/oc-server3
  git clone git@github.com:<DeinBenutzername>/oc-server3


Nun wird bei dir ein Verzeichnis <code>oc-server3/.git</code> angelegt, das zunächst eine 1:1-Kopie deines Github-Forks ist (der zunächst eine 1:1-Kopie des Opencaching-Deutschland-Repos ist), und von dort der komplette aktuelle OC.de-Code in Unterverzeichnisse von <code>oc-server3</code> ausgecheckt. In <code>oc-server3</code> befinden sich also sowohl deine Arbeitsdaten als auch der lokale Repository-Klon. <code>oc-server3/.git/config</code> ist die Konfigurationsdatei des lokalen Repositories, die du aber nur selten von Hand bearbeiten wirst.
Nun wird bei dir ein Verzeichnis <code>oc-server3/.git</code> angelegt, das zunächst eine 1:1-Kopie deines GitHub-Forks ist (der zunächst eine 1:1-Kopie des Opencaching-Deutschland-Repos ist), und von dort der komplette aktuelle OC.de-Code in Unterverzeichnisse von <code>oc-server3</code> ausgecheckt. In <code>oc-server3</code> befinden sich also sowohl deine Arbeitsdaten als auch der lokale Repository-Klon. <code>oc-server3/.git/config</code> ist die Konfigurationsdatei des lokalen Repositories, die du aber nur selten von Hand bearbeiten wirst.


Dein Github-Fork heißt in deinem lokalen Repository ''origin''; über diesen Name kannst du mit verschiedenen Git-Kommandos darauf zugreifen. Um die Konfiguration abzuschließen, muss zusätzlich noch der ''upstream'' definiert werden - das Repository, aus dem du neue Daten abrufst. Dies ist nicht dein eigener Fork, sondern du beziehst die Daten direkt von OpencachingDeutschland. Navigiere dazu ins Verzeichnis <code>oc-server3</code> und führe dann folgenden Befehl aus:
Dein GitHub-Fork heißt in deinem lokalen Repository ''origin''; über diesen Name kannst du mit verschiedenen Git-Kommandos darauf zugreifen. Um die Konfiguration abzuschließen, muss zusätzlich noch der ''upstream'' definiert werden - das Repository, aus dem du neue Daten abrufst. Dies ist nicht dein eigener Fork, sondern du beziehst die Daten direkt von OpencachingDeutschland. Navigiere dazu ins Verzeichnis <code>oc-server3</code> und führe dann folgenden Befehl aus:
  git remote add upstream http://github.com/OpencachingDeutschland/oc-server3
 
  git remote add upstream git@github.com:OpencachingDeutschland/oc-server3


Mit <code>git remote -v</code> kannst du dir nun alle "remote"-Repositories anzeigen lassen, die in deinem Klon eingestellt sind.
Mit <code>git remote -v</code> kannst du dir nun alle "remote"-Repositories anzeigen lassen, die in deinem Klon eingestellt sind.
Zeile 75: Zeile 76:
in roter Farbe an, welche Dateien geändert oder hinzugefügt wurden, und
in roter Farbe an, welche Dateien geändert oder hinzugefügt wurden, und
  git diff
  git diff
die Änderungen im Einzelnen. Falls dein Editor bzw. deine Eintwicklungsumgebung irgendwelche zusätzlichen Dateien angelegt hat, kannst du diese in <code>.git/info/exclude</code> eintragen, damit sie nicht ins Repository gelangen.
die Änderungen im Einzelnen. Falls dein Editor bzw. deine Entwicklungsumgebung irgendwelche zusätzlichen Dateien angelegt hat, kannst du diese in <code>.git/info/exclude</code> eintragen, damit sie nicht ins Repository gelangen.


Als nächstes musst du Git mitteilen, dass die Daten zum aktiven Branch hinzugefügt werden sollen; dies geschieht mit
Als nächstes musst du Git mitteilen, dass die Daten zum aktiven Branch hinzugefügt werden sollen; dies geschieht mit
Zeile 93: Zeile 94:
Um den Commit mit einem Ticket in der [[Entwicklung/Todo-Liste|Redmine-Todo-Liste]] zu verknüpfen, kannst du im Kommentar das Stichwort "updates #nnn" einfügen, mit #nnn = Redmine-Ticketnummer. Der Commit erscheint dann innerhalb des Tickets, sobald er geprüft und in den ''development''-Branch übernommen wurde.
Um den Commit mit einem Ticket in der [[Entwicklung/Todo-Liste|Redmine-Todo-Liste]] zu verknüpfen, kannst du im Kommentar das Stichwort "updates #nnn" einfügen, mit #nnn = Redmine-Ticketnummer. Der Commit erscheint dann innerhalb des Tickets, sobald er geprüft und in den ''development''-Branch übernommen wurde.


==== Exkurs: commits ====
==== Exkurs: Commits ====
   
   
Commits sind das Hauptelement der Arbeit mit Git. Jeder Branch ist eine bestimmte Abfolge von Commits. Verschiedene Branches unterscheiden sich dadurch, welche Commits sie enthalten. Ein Commit ist ein Patch, der eine oder mehrere Dateien verändert, hinzufügt und/oder löscht. Jeder Commit hat einen eindeutigen Hashcode, der im Log angezeigt wird. Über diesen Code lassen sich Commits einzeln herauspicken, rückgängig machen, als Diff anzeigen etc. Dabei genügt die Angabe der ersten paar Zeichen, sofern sie eindeutig sind; üblich als Kurzform sind die ersten 7-10 Zeichen.
Commits sind das Hauptelement der Arbeit mit Git. Jeder Branch ist eine bestimmte Abfolge von Commits. Verschiedene Branches unterscheiden sich dadurch, welche Commits sie enthalten. Ein Commit ist ein Patch, der eine oder mehrere Dateien verändert, hinzufügt und/oder löscht. Jeder Commit hat einen eindeutigen Hashcode, der im Log angezeigt wird. Über diesen Code lassen sich Commits einzeln herauspicken, rückgängig machen, als Diff anzeigen etc. Dabei genügt die Angabe der ersten paar Zeichen, sofern sie eindeutig sind; üblich als Kurzform sind die ersten 7-10 Zeichen.
Zeile 147: Zeile 148:
* Hochladen
* Hochladen
*# <code>git push origin 1234-neues-Feature</code>
*# <code>git push origin 1234-neues-Feature</code>
*# ''Branch 1234-neues-Feature'' im Github aufrufen und Pull Request starten
*# ''Branch 1234-neues-Feature'' auf GitHub aufrufen und Pull Request starten
* Nicht mehr benötigte Branches löschen
* Nicht mehr benötigte Branches löschen
*# lokal: <code>git checkout development</code> / <code>git branch -d 1234-neues-Feature</code>
*# lokal: <code>git checkout development</code> / <code>git branch -d 1234-neues-Feature</code>
Zeile 185: Zeile 186:
* <code>git revert commit-ID</code>
* <code>git revert commit-ID</code>
* <code>git push</code>
* <code>git push</code>
* evt. Pull-Request auf dem Github, wenn es bereits im Upstream angekommen war
* evt. Pull-Request auf dem GitHub, wenn es bereits im Upstream angekommen war
   
   
Den Kommentar des letzten, noch nicht "gepushten" Commit korrigieren:  
Den Kommentar des letzten, noch nicht "gepushten" Commit korrigieren:  
Zeile 193: Zeile 194:
   
   
Wenn du z.B. den Branch ''1234-new-feature'' von Entwickler ''heinz'' testen möchtest, kannst du ihn in einen Testbranch bei dir herunterladen. Zunächst musst du ''heinz''' Fork einmalig als weitere Upstream definieren:
Wenn du z.B. den Branch ''1234-new-feature'' von Entwickler ''heinz'' testen möchtest, kannst du ihn in einen Testbranch bei dir herunterladen. Zunächst musst du ''heinz''' Fork einmalig als weitere Upstream definieren:
  git remote add heinz http://github.com/heinz/oc-server3
  git remote add heinz git@github.com:heinz/oc-server3
Dann legst du bei dir einen Testbranch an, am besten auf Basis aktuellster Daten ...
Dann legst du bei dir einen Testbranch an, am besten auf Basis aktuellster Daten ...
  git checkout development
  git checkout development