Entwicklung/Git: Unterschied zwischen den Versionen

keine Bearbeitungszusammenfassung
Keine Bearbeitungszusammenfassung
Zeile 57: Zeile 57:
== Daten bearbeiten und hochladen ==
== Daten bearbeiten und hochladen ==
   
   
Nach dem ersten Auschecken ist der ''master''-Branch aktiv. Dieser enthält den aktuellen Entwicklungsstand. Welcher Branch aktiv ist, siehst du mit
Nach dem ersten Auschecken ist der ''development''-Branch aktiv. Dieser enthält den aktuellen Entwicklungsstand. Welcher Branch aktiv ist, siehst du mit
  <code>git branch</code>  
  <code>git branch</code>  
Unser Standard-Workflow sieht vor, dass '''nie im Master gearbeitet wird'''. Stattdessen musst du dir - ausgehend von ''master'' - für jede Aufgabe einen Arbeitsbranch anlegen:
Unser Standard-Workflow sieht vor, dass '''nie im development gearbeitet wird'''. Stattdessen musst du dir - ausgehend von ''development'' - für jede Aufgabe einen Arbeitsbranch anlegen:
  <code>git checkout -b 1234-new-feature master</code>  
  <code>git checkout -b 1234-new-feature development</code>  
Die vorangestellte Nummer ist eine Ticketnummer aus der Todo-Liste. Wenn es keine passende gibt, lässt du sie weg. Verwende nach Möglichkeit englische Namen und Kommentare, denn das OC-Projekt ist international vernetzt. Nun kannst du mit <code>git branch</code> sehen, dass es in deinem lokalen Repo zwei Branches gibt, und der neu angelegte ist aktiv. Mit dem Kommando <code>git checkout Branchname</code> kannst du zwischen den Branches hin- und herwechseln; dabei wird jeweils der Code in den Arbeitsdaten entsprechend ausgetauscht.
Die vorangestellte Nummer ist eine Ticketnummer aus der Todo-Liste. Wenn es keine passende gibt, lässt du sie weg. Verwende nach Möglichkeit englische Namen und Kommentare, denn das OC-Projekt ist international vernetzt. Nun kannst du mit <code>git branch</code> sehen, dass es in deinem lokalen Repo zwei Branches gibt, und der neu angelegte ist aktiv. Mit dem Kommando <code>git checkout Branchname</code> kannst du zwischen den Branches hin- und herwechseln; dabei wird jeweils der Code in den Arbeitsdaten entsprechend ausgetauscht.


Beim Anlegen des Branches sind wir davon ausgegangen, das unmittelbar zuvor der Klon angelegt wurde und die lokale master-Kopie aktuell ist. Wenn Letzteres evtl. nicht der Fall ist, solltest du sie vor dem Anlegen des neuen Branches aktualisieren:
Beim Anlegen des Branches sind wir davon ausgegangen, das unmittelbar zuvor der Klon angelegt wurde und die lokale development-Kopie aktuell ist. Wenn Letzteres evtl. nicht der Fall ist, solltest du sie vor dem Anlegen des neuen Branches aktualisieren:
  git checkout master
  git checkout development
  git pull upstream
  git pull upstream
  git checkout -b 1234-new-feature [master]  
  git checkout -b 1234-new-feature [development]  


Nun ist es soweit: Du kannst deine ersten Änderungen am OC-Code vornehmen und hochladen! Zum Bearbeiten musst du einen UTF8-fähigen Editor verwenden. Dass er das ist, erkennst du an den zwei japanischen Sonderzeichen oben in jeder Quelltextdatei: Wenn dort zwei Fragezeichen, Klötzchen oder Ähnliches erscheinen, ist dein Editor falsch eingestellt oder ungeeignet. Zum Thema Editoren/IDEs siehe auch im Forum: "[http://forum.opencaching.de/index.php?topic=2150.0 Git-UI / PHP-IDE]"
Nun ist es soweit: Du kannst deine ersten Änderungen am OC-Code vornehmen und hochladen! Zum Bearbeiten musst du einen UTF8-fähigen Editor verwenden. Dass er das ist, erkennst du an den zwei japanischen Sonderzeichen oben in jeder Quelltextdatei: Wenn dort zwei Fragezeichen, Klötzchen oder Ähnliches erscheinen, ist dein Editor falsch eingestellt oder ungeeignet. Zum Thema Editoren/IDEs siehe auch im Forum: "[http://forum.opencaching.de/index.php?topic=2150.0 Git-UI / PHP-IDE]"
Zeile 90: Zeile 90:
siehst du nun, dass ein neuer ''commit'' in die Versionsgeschichte des aktiven Branches eingefügt wurde. Wahlweise kannst du auch mit <code>git log --stat</code> nochmals alle geänderten Dateien anzeigen lassen.
siehst du nun, dass ein neuer ''commit'' in die Versionsgeschichte des aktiven Branches eingefügt wurde. Wahlweise kannst du auch mit <code>git log --stat</code> nochmals alle geänderten Dateien anzeigen lassen.


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 ''master''-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 ====
Zeile 106: Zeile 106:
Zunächst solltest du deine Daten nochmal auf den aktuellen Stand bringen. Damit ist sichergestellt, dass deine Änderungen mit dem aktuellsten OC-Code funktionieren:
Zunächst solltest du deine Daten nochmal auf den aktuellen Stand bringen. Damit ist sichergestellt, dass deine Änderungen mit dem aktuellsten OC-Code funktionieren:
  git fetch upstream
  git fetch upstream
  git rebase upstream/master
  git rebase upstream/development


Das erste Kommando aktualisiert deine lokale Kopie der Upstream-Branches (die du mit <code>git branch -r</code> auflisten kannst), bzw. legt diese erstmalig an. Das zweite übernimmt alle neuen ''commits'' aus dem Upstream - also dem OC-Hauptrepository - in deinen aktiven Branch, und zwar fügt es sie ''vor'' deine eigenen Änderungen ein! Deine Änderungen werden auf Basis des aktuellen OC-Codestandes neu aufgesetzt (re-based), d.h. sie werden als Patch auf diesen Codestand angewandt. Beide Kommandos lassen sich auch zu einem zusammenfassen:
Das erste Kommando aktualisiert deine lokale Kopie der Upstream-Branches (die du mit <code>git branch -r</code> auflisten kannst), bzw. legt diese erstmalig an. Das zweite übernimmt alle neuen ''commits'' aus dem Upstream - also dem OC-Hauptrepository - in deinen aktiven Branch, und zwar fügt es sie ''vor'' deine eigenen Änderungen ein! Deine Änderungen werden auf Basis des aktuellen OC-Codestandes neu aufgesetzt (re-based), d.h. sie werden als Patch auf diesen Codestand angewandt. Beide Kommandos lassen sich auch zu einem zusammenfassen:
  git pull --rebase upstream master
  git pull --rebase upstream development


'''Verwende niemals ein einfaches <code>git pull</code> (ohne <code>--rebase</code>) in einem Arbeitsbranch!''' Es würde die Versionsgeschichte unlesbar machen und das Zurückverfolgen von Codeänderungen verhindern.
'''Verwende niemals ein einfaches <code>git pull</code> (ohne <code>--rebase</code>) in einem Arbeitsbranch!''' Es würde die Versionsgeschichte unlesbar machen und das Zurückverfolgen von Codeänderungen verhindern.
Zeile 119: Zeile 119:
Nun kannst du deinen neuen Branch mit
Nun kannst du deinen neuen Branch mit
  <code>git push origin 1234-new-feature</code>  
  <code>git push origin 1234-new-feature</code>  
in deinen Fork hochladen. Wenn du auf [http://github.com/ http://github.com/<DeinUsername>/oc-server3] links die Branch-Dropdown-Box aufklappst, oder weiter rechts auf "branches" klickst, sollte dort der neue Branch auftauchen (manchmal mit etwas Verzögerung). Wenn du oben auf "Network" klickst, siehst du wie dein neuer Branch vom master abzweigt. Jeder Punkt in diesem Diagramm steht für einen ''commit''.
in deinen Fork hochladen. Wenn du auf [http://github.com/ http://github.com/<DeinUsername>/oc-server3] links die Branch-Dropdown-Box aufklappst, oder weiter rechts auf "branches" klickst, sollte dort der neue Branch auftauchen (manchmal mit etwas Verzögerung). Wenn du oben auf "Network" klickst, siehst du wie dein neuer Branch vom development abzweigt. Jeder Punkt in diesem Diagramm steht für einen ''commit''.


Wenn dein Branch fertig ist und in den master übernommen werden soll, wählst du ihn aus der Branches-Liste aus und klickst oben auf "Pull Request"; hier kannst du noch einen zusätzlichen Kommentar angeben. Der Code Maintainer wird per E-Mail informiert und wird deinen Code prüfen und ggf. übernehmen.
Wenn dein Branch fertig ist und in den development übernommen werden soll, wählst du ihn aus der Branches-Liste aus und klickst oben auf "Pull Request"; hier kannst du noch einen zusätzlichen Kommentar angeben. Der Code Maintainer wird per E-Mail informiert und wird deinen Code prüfen und ggf. übernehmen.


In diesem Fall war es wahrscheinlich nur ein Test, daher kannst du den Branch nun mit
In diesem Fall war es wahrscheinlich nur ein Test, daher kannst du den Branch nun mit
  git push origin :1234-new-feature
  git push origin :1234-new-feature
wieder aus deinem Fork löschen. Wenn du ihn auch lokal wieder löschen willst, geht das mit
wieder aus deinem Fork löschen. Wenn du ihn auch lokal wieder löschen willst, geht das mit
  git checkout master
  git checkout development
  git branch -D 1234-new-feature  
  git branch -D 1234-new-feature  


Das große <code>-D</code> ermöglicht es, einen Branch zu verwerfen, der nicht weiterverwendet wurde. Wenn du stattdessen <code>-d</code> angibst, sind nur Branches löschbar die bereits in einen anderen Branch (z.B. den master) übernommen wurden, wo durch die Löschung also keine Daten verloren gehen können. '''Im Zweifelsfall verwende immer -d'''; dabei kann nichts versehentlich verloren gehen.
Das große <code>-D</code> ermöglicht es, einen Branch zu verwerfen, der nicht weiterverwendet wurde. Wenn du stattdessen <code>-d</code> angibst, sind nur Branches löschbar die bereits in einen anderen Branch (z.B. den development) übernommen wurden, wo durch die Löschung also keine Daten verloren gehen können. '''Im Zweifelsfall verwende immer -d'''; dabei kann nichts versehentlich verloren gehen.


==== Zusammenfassung des OC-Git-Standard-Workflow ====
==== Zusammenfassung des OC-Git-Standard-Workflow ====
Zeile 135: Zeile 135:
Neuen Branch für eine neue Aufgabe anlegen:
Neuen Branch für eine neue Aufgabe anlegen:


1. <code>git checkout master</code><br/>
1. <code>git checkout development</code><br/>
2. <code>git pull upstream</code><br/>
2. <code>git pull upstream</code><br/>
3. <code>git checkout -b 1234-new-feature</code>
3. <code>git checkout -b 1234-new-feature</code>
Zeile 145: Zeile 145:
5. mit <code>git status</code> / <code>git diff</code> lokale Änderungen kontrollieren<br />
5. mit <code>git status</code> / <code>git diff</code> lokale Änderungen kontrollieren<br />
6. Änderung mit <code>git add</code> / <code>git commit</code> ins lokale Repo einchecken<br />
6. Änderung mit <code>git add</code> / <code>git commit</code> ins lokale Repo einchecken<br />
7. mit <code>git pull --rebase upstream master</code> auf aktuellen OC-Code aufsetzen<br />
7. mit <code>git pull --rebase upstream development</code> auf aktuellen OC-Code aufsetzen<br />
8. weiter bei 4, wenn der Code noch nicht fertig ist
8. weiter bei 4, wenn der Code noch nicht fertig ist


Zeile 155: Zeile 155:
Nicht mehr benötigte Branches löschen:
Nicht mehr benötigte Branches löschen:


11. lokal: <code>git checkout master</code> / <code>git branch -d 1234-neues-Feature</code><br />
11. lokal: <code>git checkout development</code> / <code>git branch -d 1234-neues-Feature</code><br />
12. auf dem Fork: <code>git push origin :1234-neues-Feature</code>
12. auf dem Fork: <code>git push origin :1234-neues-Feature</code>


Zeile 169: Zeile 169:
   
   
Wenn du selbst gerade nichts programmieren willst, sondern dir einfach nur ein Update vom OC-Server holen und anschauen, machst du
Wenn du selbst gerade nichts programmieren willst, sondern dir einfach nur ein Update vom OC-Server holen und anschauen, machst du
  git checkout master
  git checkout development
  git pull upstream  
  git pull upstream  
Wenn du mehrere Branches mit eigenen Änderungen angelegt hast, und diese alle im Zusammenhang testen möchtest, kannst du dir dafür einen Testbranch anlegen:
Wenn du mehrere Branches mit eigenen Änderungen angelegt hast, und diese alle im Zusammenhang testen möchtest, kannst du dir dafür einen Testbranch anlegen:
  git checkout -b test master
  git checkout -b test development
  git merge 1234-new-feature
  git merge 1234-new-feature
  git merge 2345-my-bugfix
  git merge 2345-my-bugfix
Zeile 201: Zeile 201:
  git remote add heinz http://github.com/heinz/oc-server3
  git remote add heinz http://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 master
  git checkout development
  git pull upstream
  git pull upstream
  git checkout -b tolles-heinz-feature  
  git checkout -b tolles-heinz-feature  
Zeile 209: Zeile 209:
== Der stable-Branch ==
== Der stable-Branch ==
   
   
Neben dem Master gibt es im OC-Repository einen Branch "stable". Dieser enthält immer den gleichen Stand wie das Produktivsystem www.opencaching.de. Neue Features werden im Master entwickelt und getestet und später über den Stable-Branch freigegeben.
Neben dem development gibt es im OC-Repository einen Branch "stable". Dieser enthält immer den gleichen Stand wie das Produktivsystem www.opencaching.de. Neue Features werden im development entwickelt und getestet und später über den Stable-Branch freigegeben.


Mit dem Stable-Branch wirst du nur dann zu tun haben, wenn du einen "Hotfix" schreibst - eine dringende Korrektur, die sofort freigegeben werden soll. Diese setzt du auf dem Stable statt dem Master auf; der übrige Workflow ist der gleiche wie oben beschrieben.
Mit dem Stable-Branch wirst du nur dann zu tun haben, wenn du einen "Hotfix" schreibst - eine dringende Korrektur, die sofort freigegeben werden soll. Diese setzt du auf dem Stable statt dem development auf; der übrige Workflow ist der gleiche wie oben beschrieben.


== Vereinfachter Workflow ==
== Vereinfachter Workflow ==
   
   
Der oben beschriebene Workflow ist Pflicht für alle Entwickler, die Code zu OC.de beitragen. Wer nur hin und wieder mal eine Grafik oder einen Text beisteuert, kann ausnahmsweise auch ohne separate Branches arbeiten. In diesem Fall ist ein '''einfaches <code>git pull</code> im Master-Branch verboten'''! Stattdessen muss überall, wo oben <code>git pull upstream</code> steht, stattdessen
Der oben beschriebene Workflow ist Pflicht für alle Entwickler, die Code zu OC.de beitragen. Wer nur hin und wieder mal eine Grafik oder einen Text beisteuert, kann ausnahmsweise auch ohne separate Branches arbeiten. In diesem Fall ist ein '''einfaches <code>git pull</code> im development-Branch verboten'''! Stattdessen muss überall, wo oben <code>git pull upstream</code> steht, stattdessen
  <code>git pull --rebase upstream master</code>  
  <code>git pull --rebase upstream development</code>  
verwendet werden! Der vereinfachte Ablauf ist dann:
verwendet werden! Der vereinfachte Ablauf ist dann:


Zeile 222: Zeile 222:
2. mit <code>git status</code> / <code>git diff</code> lokale Änderungen kontrollieren<br>
2. mit <code>git status</code> / <code>git diff</code> lokale Änderungen kontrollieren<br>
3. Änderung mit <code>git add</code> / <code>git commit</code> ins lokale Repo einchecken<br>
3. Änderung mit <code>git add</code> / <code>git commit</code> ins lokale Repo einchecken<br>
4. mit <code>git pull --rebase upstream master</code> auf aktuellen OC-Code aufsetzen<br>
4. mit <code>git pull --rebase upstream development</code> auf aktuellen OC-Code aufsetzen<br>
5. weiter bei 1, wenn der Code noch nicht fertig ist<br>
5. weiter bei 1, wenn der Code noch nicht fertig ist<br>
6. <code>git push origin</code><br>
6. <code>git push origin</code><br>