Git Workflow
Falls jemand einen einen Schubser für die Arbeit mit Git benötigt: https://github.com/diaspora/diaspora/wiki/Git-Workflow hat mit da ganz gut geholfen.
[url=http://www.flopp-caching.de/]Flopps Tolle Karte[/url] | [url=http://www.florian-pigorsch.de/oc]OC[/url] | [url=http://www.florian-pigorsch.de/gc]GC[/url] | [url=http://florian-pigorsch.de/+]G+[/url] | [url=http://florian-pigorsch.de/t]Tw[/url] | [url=http://florian-pigorsch.de/fb]Fb[/url]
-
following
Danke. Ich hatte prompt in meinem Master-Branch entwickelt ...
Kann es sein, dass die Nummer 8 überflüssig ist?
8. Fetch upstream ($ git fetch upstream)
9. Update local master ($ git checkout master; git pull upstream master)
pull = fetch + merge. Ich hab das fetch eben weggelassen und es scheint funktioniert zu haben.
Kann es sein, dass die Nummer 8 überflüssig ist?
8. Fetch upstream ($ git fetch upstream)
9. Update local master ($ git checkout master; git pull upstream master)
pull = fetch + merge. Ich hab das fetch eben weggelassen und es scheint funktioniert zu haben.
Oh, da bin ich überfragt.
Es ist aber auch das erste Mal, dass ich Git einigermaßen sinnvoll einsetze
Es ist aber auch das erste Mal, dass ich Git einigermaßen sinnvoll einsetze
[url=http://www.flopp-caching.de/]Flopps Tolle Karte[/url] | [url=http://www.florian-pigorsch.de/oc]OC[/url] | [url=http://www.florian-pigorsch.de/gc]GC[/url] | [url=http://florian-pigorsch.de/+]G+[/url] | [url=http://florian-pigorsch.de/t]Tw[/url] | [url=http://florian-pigorsch.de/fb]Fb[/url]
-
following
Bei dieser Arbeitsmethode mit einem Branch pro Task muss man höllisch aufpassen, dass man die neuen Branches jeweils auf dem Master aufsetzt und nicht auf dem gerade aktiven Branch des letzten Tasks.
* git checkout -b Bugfix_A
* programmieren
* einchecken und push
* git checkout master
* git checkout -b Bugfix_B
Wenn man das checkout master vergisst, beinhaltet Bugfix_B auch Bugfix_A. Man zwar jeden Fehler irgendwie wieder rückgängig machen - aber dazu muss man ihn bemerken ...
* git checkout -b Bugfix_A
* programmieren
* einchecken und push
* git checkout master
* git checkout -b Bugfix_B
Wenn man das checkout master vergisst, beinhaltet Bugfix_B auch Bugfix_A. Man zwar jeden Fehler irgendwie wieder rückgängig machen - aber dazu muss man ihn bemerken ...
-
following
Was mache ich, wenn ich nebenbei irgendwelche Kleinigkeiten ändern will, die nichts mit einer bestimmten zugewiesenen Aufgabe zu tun haben - z.B. irgendwo Kommentare im Quelltext einfügen, eine redundante Anweisung entfernen, einen Tippfehler in einer Meldung korrigieren? Einfach in irgendeinen Branch/Commit/Push/Pull-Request mit reinpacken? Oder separat commiten, aber ansonsten mit was anderem Zusammenpacken? Oder einen eigenen Branch anlegen wo ich so Kleinkram sammle und hin und wieder einen Pull Request darauf?
Gestern hatte ich einen Fall, wo mir beim Testen der Watchlist ein absoluter Pfad in util/watchlist/settings.inc.php auffiel; den hab ich gerade mit dem gleichen Commit auf relativ umgestellt: https://github.com/following5/server-3. ... list-links. Ok? Oder besser separater Commit? Oder gar komplett separieren mit eigenem Ticket bis eingenem Pull-Request?
Gestern hatte ich einen Fall, wo mir beim Testen der Watchlist ein absoluter Pfad in util/watchlist/settings.inc.php auffiel; den hab ich gerade mit dem gleichen Commit auf relativ umgestellt: https://github.com/following5/server-3. ... list-links. Ok? Oder besser separater Commit? Oder gar komplett separieren mit eigenem Ticket bis eingenem Pull-Request?
-
following
Also, dieser Workflow mit den getrennten Branches ist eine feine Sache - so kann Robert sich aus allen offenen Patches einzelne rauspicken, unabhängig von den anderen. Ohne Branches müsste er dazu mit einzelnen Commits rumjonglieren, das wäre äußerst mühsam und fehlerträchtig. Hier mal der aktuelle Graph:
https://github.com/OpencachingDeutschla ... .0/network
Einfach mit der Maus draufklicken und ziehen, zum hin- und herschieben.
Für Nr. 3970, 4009 und 4505 hab ich eben mal das rebase getestet, um den Fix #4487 mit reinzuziehen.* 4487 ist die blaue Linie oben vom 23. zum 25.7., den hat Robert heute morgen in den Master übernommen (Genaueres sieht man, wenn man die Maus auf den blauen bzw. den folgenden schwarzen Punkt bewegt).
* Hier gab's allerdings ein kleines Problem: Nach dem Rebase und beim push-Versuch meinte Git, der Stand der drei Branches im Remote-Repository sei einen Commit "ahead" und hat verlangt, dass ich diesen erst reinmerge vor dem nächsten Commit. Der Merge mit den drei Remote-Branches verlief dann erwartungsgemäß ohne jede Codeänderung, und nun hängen die drei Punkte nicht sauber hinten an Roberts Commit von heute morgen, sondern haben eine zusätzliche Querverbindung zurück zur ursprünglichen Master-Basis. Woran liegt's? -- Nachtrag: habe es durch entfernen der Merge-Commits und ein push force korrigiert. Wäre auch direkt per push force gegangen.
Um alles im Zusammenhang testen zu können, habe ich mir lokal einen Branch "test" angelegt, in den ich alle meine Änderungen reinmerge. Achtung: Zum Updaten eines solchen Testbranches macht man besser ein "merge master" statt "rebase master", weil letzteres jedesmal sämtliche Merge-Konflikte zwischen den Einzelteilen reproduziert.
Ganz wichtig, ich wiederhol's nochmal: Neue Branches für unabhängige Patches immer auf dem Master aufsetzen! Wenn man's falsch gemacht hat und der Patch noch nicht bei Robert angekommen ist, kann man's auch nachträglich korrigieren:
... alles außer den letzten Commits rauslöschen, die zum aktuellen Branch gehören, speichern und - falls es schon im Git liegt - ein Brutalupdate machen:
Ich denke dass dieser komplexe Workflow nur für die Entwickler nötig ist. Wenn jemand wie Micha hin und wieder nen Text oder ne Grafik ändert, kann er das auch inkrementell in seinem Master-Branch machen. Wenn was nicht stimmt, wird's halt vorübergehend auf den letzten korrekten Stand zurückgesetzt.
https://github.com/OpencachingDeutschla ... .0/network
Einfach mit der Maus draufklicken und ziehen, zum hin- und herschieben.
Für Nr. 3970, 4009 und 4505 hab ich eben mal das rebase getestet, um den Fix #4487 mit reinzuziehen.* 4487 ist die blaue Linie oben vom 23. zum 25.7., den hat Robert heute morgen in den Master übernommen (Genaueres sieht man, wenn man die Maus auf den blauen bzw. den folgenden schwarzen Punkt bewegt).
* Hier gab's allerdings ein kleines Problem: Nach dem Rebase und beim push-Versuch meinte Git, der Stand der drei Branches im Remote-Repository sei einen Commit "ahead" und hat verlangt, dass ich diesen erst reinmerge vor dem nächsten Commit. Der Merge mit den drei Remote-Branches verlief dann erwartungsgemäß ohne jede Codeänderung, und nun hängen die drei Punkte nicht sauber hinten an Roberts Commit von heute morgen, sondern haben eine zusätzliche Querverbindung zurück zur ursprünglichen Master-Basis. Woran liegt's? -- Nachtrag: habe es durch entfernen der Merge-Commits und ein push force korrigiert. Wäre auch direkt per push force gegangen.
Um alles im Zusammenhang testen zu können, habe ich mir lokal einen Branch "test" angelegt, in den ich alle meine Änderungen reinmerge. Achtung: Zum Updaten eines solchen Testbranches macht man besser ein "merge master" statt "rebase master", weil letzteres jedesmal sämtliche Merge-Konflikte zwischen den Einzelteilen reproduziert.
Ganz wichtig, ich wiederhol's nochmal: Neue Branches für unabhängige Patches immer auf dem Master aufsetzen! Wenn man's falsch gemacht hat und der Patch noch nicht bei Robert angekommen ist, kann man's auch nachträglich korrigieren:
Code: Alles auswählen
git rebase -i master
Code: Alles auswählen
git push --force
Ich denke dass dieser komplexe Workflow nur für die Entwickler nötig ist. Wenn jemand wie Micha hin und wieder nen Text oder ne Grafik ändert, kann er das auch inkrementell in seinem Master-Branch machen. Wenn was nicht stimmt, wird's halt vorübergehend auf den letzten korrekten Stand zurückgesetzt.
Zuletzt geändert von following am 25.07.2012, 22:02, insgesamt 1-mal geändert.
-
following
[quote="flopp"]
Falls jemand einen einen Schubser für die Arbeit mit Git benötigt: https://github.com/diaspora/diaspora/wiki/Git-Workflow hat mit da ganz gut geholfen.
[/quote]
Da ist noch ein Fehler drin: Schritt 10 und 11 sind zu vertauschen, sonst macht Schritt 8/9 keinen Sinn. Und die Schritte 8, 9 und 11 lassen sich per pull --rebase zu einem kombinieren.
neuen lokalen Branch anlegen:
5. git checkout master
6. git pull upstream, um sicherzugehen dass der Master aktuell ist
7. git checkout -b 123-neues-Feature
Programmierzyklen:
8. Code schreiben... zwischenzeitlich gibt es Änderungen am OC-Master
9. mit git status / git diff die lokalen Änderungen kontrollieren
10. Änderungen mit git add / commit ins lokale Repo einchecken; vereinfacht: git commit -am 'Kommentar', um alle Änderungen einzuchecken. Neue Dateien müssen aber vorher explizit mit "add" eingefügt werden!
11. git pull --rebase upstream master
12. weiter bei 8, falls der Code noch nicht fertig ist
Falls es eine längerwierige Aufgabe ist und bei Schritt 11 immer wieder die gleichen Merge-Konflikte enstehen, kann man deren Auflösung mit git rerere automatisieren.
einchecken:
13. git push origin 123-neues-Feature
14. Branch 123-neues-Feature im Github aufrufen und Pull Request starten
Wenn die Änderungen im OC-Code angekommen sind und der lokale Branch nicht weiterentwickelt wird, kann man ihn löschen:
15. git checkout master; git branch -d 123-neues-Feature
Er ist damit nicht verloren, sondern kann notfalls wieder vom Remote ausgecheckt werden.
Arbeiten an mehreren Patches
Wenn man an mehreren Patches gleichzeitig arbeitet, sollte der aktuelle Branch "clean" sein bevor man zu einem anderen wechselt. Dazu gibt es verschiedene Möglichkeiten:
- Änderungen mit git checkout -- . verwerfen, falls es nur ein Test war.
- Änderungen mit git add / commit im lokalen Repo einchecken, wenn sie brauchbar sind
- Änderungen mit git stash in einen Zwischenspeicher schieben und später mit git stash pop wieder zurückholen. Der Stash kann benannt werden, damit man den Überblick behält.
Falls jemand einen einen Schubser für die Arbeit mit Git benötigt: https://github.com/diaspora/diaspora/wiki/Git-Workflow hat mit da ganz gut geholfen.
[/quote]
Da ist noch ein Fehler drin: Schritt 10 und 11 sind zu vertauschen, sonst macht Schritt 8/9 keinen Sinn. Und die Schritte 8, 9 und 11 lassen sich per pull --rebase zu einem kombinieren.
neuen lokalen Branch anlegen:
5. git checkout master
6. git pull upstream, um sicherzugehen dass der Master aktuell ist
7. git checkout -b 123-neues-Feature
Programmierzyklen:
8. Code schreiben... zwischenzeitlich gibt es Änderungen am OC-Master
9. mit git status / git diff die lokalen Änderungen kontrollieren
10. Änderungen mit git add / commit ins lokale Repo einchecken; vereinfacht: git commit -am 'Kommentar', um alle Änderungen einzuchecken. Neue Dateien müssen aber vorher explizit mit "add" eingefügt werden!
11. git pull --rebase upstream master
12. weiter bei 8, falls der Code noch nicht fertig ist
Falls es eine längerwierige Aufgabe ist und bei Schritt 11 immer wieder die gleichen Merge-Konflikte enstehen, kann man deren Auflösung mit git rerere automatisieren.
einchecken:
13. git push origin 123-neues-Feature
14. Branch 123-neues-Feature im Github aufrufen und Pull Request starten
Wenn die Änderungen im OC-Code angekommen sind und der lokale Branch nicht weiterentwickelt wird, kann man ihn löschen:
15. git checkout master; git branch -d 123-neues-Feature
Er ist damit nicht verloren, sondern kann notfalls wieder vom Remote ausgecheckt werden.
Arbeiten an mehreren Patches
Wenn man an mehreren Patches gleichzeitig arbeitet, sollte der aktuelle Branch "clean" sein bevor man zu einem anderen wechselt. Dazu gibt es verschiedene Möglichkeiten:
- Änderungen mit git checkout -- . verwerfen, falls es nur ein Test war.
- Änderungen mit git add / commit im lokalen Repo einchecken, wenn sie brauchbar sind
- Änderungen mit git stash in einen Zwischenspeicher schieben und später mit git stash pop wieder zurückholen. Der Stash kann benannt werden, damit man den Überblick behält.
[quote="following"]
Ich denke dass dieser komplexe Workflow nur für die Entwickler nötig ist. Wenn jemand wie Micha hin und wieder nen Text oder ne Grafik ändert, kann er das auch inkrementell in seinem Master-Branch machen. Wenn was nicht stimmt, wird's halt vorübergehend auf den letzten korrekten Stand zurückgesetzt.
[/quote]
Ich war wirklich irritiert über deinen Beitrag ... bis zum letzten Satz - jetzt geht es mir besser
Ich denke dass dieser komplexe Workflow nur für die Entwickler nötig ist. Wenn jemand wie Micha hin und wieder nen Text oder ne Grafik ändert, kann er das auch inkrementell in seinem Master-Branch machen. Wenn was nicht stimmt, wird's halt vorübergehend auf den letzten korrekten Stand zurückgesetzt.
[/quote]
Ich war wirklich irritiert über deinen Beitrag ... bis zum letzten Satz - jetzt geht es mir besser
Whenever I try to plan something, it doesn't seems to work out. So why plan, it only leads to disappointment! (Eddie van Halen)
-
following
[quote="4_Vs"]
Ich war wirklich irritiert über deinen Beitrag ...
[/quote]
und dabei hattest du meinen zweiten Beitrag danach noch gar nicht gesehen
Ich war wirklich irritiert über deinen Beitrag ...
[/quote]
und dabei hattest du meinen zweiten Beitrag danach noch gar nicht gesehen
[quote="following"]
[quote="4_Vs"]
Ich war wirklich irritiert über deinen Beitrag ...
[/quote]
und dabei hattest du meinen zweiten Beitrag danach noch gar nicht gesehen
[/quote]
Deswegen kam zu dem auch kein Feedback mehr
[quote="4_Vs"]
Ich war wirklich irritiert über deinen Beitrag ...
[/quote]
und dabei hattest du meinen zweiten Beitrag danach noch gar nicht gesehen
[/quote]
Deswegen kam zu dem auch kein Feedback mehr
Whenever I try to plan something, it doesn't seems to work out. So why plan, it only leads to disappointment! (Eddie van Halen)
[quote="4_Vs"]Ich war wirklich irritiert über deinen Beitrag ... [/quote]
Na dann bin ich ja froh, daß ich nicht der Einzige bin. Und dabei habe ich ein Diplom im Schrank
Aber mal im Ernst: Mir kommt die Entwicklungsumgebung reichlich komplex vor. Muß das so sein?
Oder liegt das Problem an git, und mit svn wäre es einfacher?
Na dann bin ich ja froh, daß ich nicht der Einzige bin. Und dabei habe ich ein Diplom im Schrank
Aber mal im Ernst: Mir kommt die Entwicklungsumgebung reichlich komplex vor. Muß das so sein?
Oder liegt das Problem an git, und mit svn wäre es einfacher?
-
following
[quote="mic@"]
Oder liegt das Problem an git, und mit svn wäre es einfacher?
[/quote]
Git kann wesentlich mehr als Svn, und wenn man diese Möglichkeiten nutzt, ergeben sich große Vorteile für das Management der Softwareentwicklung, siehe z.B. http://forum.geocaching-network.com/http://localhost//viewtopic.php?p=28628#p28628, erster Absatz. Man kann Git auch wie svn benutzen; so macht es ja Micha.
Wer mit Git überfordert ist, der wird auch mit dem Entwickeln von OC-Code überfordert sein, sorry. Letzteres ist eindeutig die anspruchsvollere Aufgabe. Ich hab mir das, was ich oben schrieb, auch gerade erst angeeignet; das ist alles keine Hexerei, sondern das erlent man wenn man's benutzt. Wenn die Entwicklungsprozesse stabilisiert sind, kann man den Workflow auch nochmal ordentlich dokumentieren.
Oder liegt das Problem an git, und mit svn wäre es einfacher?
[/quote]
Git kann wesentlich mehr als Svn, und wenn man diese Möglichkeiten nutzt, ergeben sich große Vorteile für das Management der Softwareentwicklung, siehe z.B. http://forum.geocaching-network.com/http://localhost//viewtopic.php?p=28628#p28628, erster Absatz. Man kann Git auch wie svn benutzen; so macht es ja Micha.
Wer mit Git überfordert ist, der wird auch mit dem Entwickeln von OC-Code überfordert sein, sorry. Letzteres ist eindeutig die anspruchsvollere Aufgabe.
Ich hab mir das, was ich oben schrieb, auch gerade erst angeeignet; das ist alles keine Hexerei, sondern das erlent man wenn man's benutzt. Wenn die Entwicklungsprozesse stabilisiert sind, kann man den Workflow auch nochmal ordentlich dokumentieren.[quote="following"]
Man kann Git auch wie svn benutzen; so macht es ja Micha.
[/quote]
Brauchst mir nicht so deutlich sagen, dass ich in der Entwicklung ein Mensch zweiter Klasse bin
Man kann Git auch wie svn benutzen; so macht es ja Micha.
[/quote]
Brauchst mir nicht so deutlich sagen, dass ich in der Entwicklung ein Mensch zweiter Klasse bin
Whenever I try to plan something, it doesn't seems to work out. So why plan, it only leads to disappointment! (Eddie van Halen)
-
following
[quote="4_Vs"]
Brauchst mir nicht so deutlich sagen, dass ich in der Entwicklung ein Mensch zweiter Klasse bin
[/quote]
Vielleicht beruhigt es dich, dass Robert bislang auch auch keine eigenen Branches verwendet. Die lohnen sich erst, wenn man mehrere unabhängige Aufgaben offen hat, und wenn darunter Dinge sind die kritische Bugs enthalten können.
Brauchst mir nicht so deutlich sagen, dass ich in der Entwicklung ein Mensch zweiter Klasse bin
[/quote]
Vielleicht beruhigt es dich, dass Robert bislang auch auch keine eigenen Branches verwendet.
Die lohnen sich erst, wenn man mehrere unabhängige Aufgaben offen hat, und wenn darunter Dinge sind die kritische Bugs enthalten können.[quote="4_Vs"]Brauchst mir nicht so deutlich sagen, dass ich in der Entwicklung ein Mensch zweiter Klasse bin [/quote]
Falls es Dich beruhigt: Ich wäre dann dritte oder vierte Klasse. Denn ich habe ja noch nicht mal einen
Branch hinbekommen. Kann aber auch daran liegen, daß mir das ganze Thema zu komplex ist und ich
es noch nicht mal schaffe, die Entwicklungsumgebung zum Laufen zu bringen. Zum Glück bin ich ja
kein Entwickler bei oc, und meine bescheidenen PHP-Kenntnisse wären hier fehl am Platze.
[/quote]Falls es Dich beruhigt: Ich wäre dann dritte oder vierte Klasse. Denn ich habe ja noch nicht mal einen
Branch hinbekommen. Kann aber auch daran liegen, daß mir das ganze Thema zu komplex ist und ich
es noch nicht mal schaffe, die Entwicklungsumgebung zum Laufen zu bringen. Zum Glück bin ich ja
kein Entwickler bei oc, und meine bescheidenen PHP-Kenntnisse wären hier fehl am Platze.