4
Bearbeitungen
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 '' | 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 | 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 | <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 | 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 | git checkout development | ||
git pull upstream | git pull upstream | ||
git checkout -b 1234-new-feature [ | 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 '' | 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/ | 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | <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 | 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> | ||