Git Workflow

[following]

Git-Datenfluss im OC-Team (vorläufig)

links/Mitte mit mehreren Arbeitsbranches, rechts mit einem Arbeitsbranch:

http://forum.geocaching-network.com/index.php?action=dlattach;topic=2125.0;attach=569

Das zentrale Repository ist der upstream für alle lokalen Repositories. Von dort kommen die neuen Daten, die der Entwicklungsleiter freigegeben hat.

Die drei Forks sind jeweils der origin des lokalen Repositories. Dorthin schickt man seine eigenen Änderungen, zur Freigabe durch den Entwicklungsleiter.

Die Daten fließen immer auf folgendem Weg:

1. Änderung in den lokalen Arbeitsdaten
2. Einchecken ins lokale Repostory mit git add / commit
3. mit git push in den origin schieben, also in den eigenen Git-Fork
4. Pull Request erstellen, damit der Entwicklungsleiter weiß dass was Neues abzuholen ist
5. merge ins zentrale Repository durch den Entwicklungsleiter
6. Verteilen in die lokalen Repositories der anderen Entwickler per git fetch upstream
7. übernehmen in den aktiven lokalen Branch und in die Arbeitsdaten mit git rebase upstream/master

Schritt 6+7 lassen sich zusammenfassen als

git pull --rebase upstream master

Falls es im aktiven lokalen Branch keine Änderungen gibt, die noch nicht im upstream sind - und NUR DANN - kann man stattdessen auch ein einfaches

git pull

machen. Wenn es bereits lokale Änderungen gibt, führt ein einfaches "pull" zu Chaos in der Versionsgeschichte, was dem Entwicklungsleiter die Arbeit erschwert. Im Zweifelsfall auf git pull verzichten und immer die rebase-Variante verwenden!


Änderungen verwerfen

Wenn man sie noch nicht "commitet" hat:
Alle geänderten Dateien:

git reset --hard

alles im aktuellen Verzeichnis und darunter:

git checkout .

nur eine bestimmte Datei:

git checkout Dateiname

Wenn man sie bereits "commitet", aber noch nicht "gepusht" hat:
Den letzten commit verwerfen:

git reset --hard HEAD~1

... oder höhere Zahlen für mehr als einen commit.

Wenn sie bereits "gepusht" wurden: Mit

git log

die commit-ID raussuchen, die man rückgängig machen will; es genügen die ersten acht Zeichen; dann

- git revert commit-ID
- git push, um es auch im origin rückgängig zu machen
- evtl. Pull Request, wenn es schon im upstream ist, um es auch dort rückgängig zu machen

Den Kommentar des letzten commit korrigieren:

git commit --amend

[4_Vs]

Hallo Peter,

vielen Dank für diese Anleitung, aber dennoch hoffe ich, dass Du mir noch einen Anschubser geben kannst ^^

Ich arbeite auf dem Mac bspw. mit SourceTree, das gibt es auch für Linux und Windows und erfordert keine Shell ... glaube/hoffe ich

Ich hänge Dir hier mal einen Screenshot dran, der Dir zeigen sollte, was ich erklärt bekommen möchte.

Unter dem Bereich "Remotes" siehst Du origin (das ist mein Remote 4Vs/server-3.0) und Upstream (habe ich so genannt), das ist OpencachingDeutschland/server-3.0 mit master & stable - ferner siehst Du unter Branches meinen lokalen branch. Soweit so gut ...

Nehmen wir an, ich habe keine aktuellen Aufgaben und möchte etwas erledigen - ich starte SourceTree und möchte als erstes meinen Remote und dann auch meinen lokalen Branch mit dem oc/server-3.0, also dem "Upstream" - sorry der Name ist verwirrend - abgleichen, also die Änderungen, die über Nacht geschehen sind bzw. eingespielt wurden abgleichen.

Mache ich das mit einem Fetch oder einem Pull from "Upstream"?

Dann ist mein Origin abgeglichen mit dem Upstream ... soweit so gut, mache ich dann einen in meinem lokalen Rep einen "Pull origin/master (tracked)?", so dass die Änderungen auf meinem lokalen System sind? Kann ich danach auch lokal ein "Rebase current changes onto master" machen?

Dies mal als ersten Schritt ... wenn ich das verstanden habe, dann kommt die andere Richtung dran

[4_Vs]

Huch .... Anhang vergessen

[following]

Hallo Micha,

Sourcetree scheint es leider nur für den Mac zu geben.

Zu deinen Fragen: Neue Daten laufen nicht vom Upstream über deinen Origin zu dir, sondern direkt vom Upstream zu dir. Siehe rechter Teil der Grafik die ich oben gepostet hatte, der mit "fetch upstream" beschriftete Pfeil: http://forum.geocaching-network.com/index.php?action=dlattach;topic=2125.0;attach=569

Wenn ich den Screenshot und die Funktionsweise von Sourcetree richtig verstehe, musst du Folgendes machen, um die neuesten Daten von OpencachingDeutschland/server-3.0 zu holen:

1. Fetch vom Upstream
2. Rebase current changes onto master. Falls diese Funktion nicht wählbar sein sollte, weil es keine "current changes" gibt, machst du stattdessen einen Merge vom Upstream/master.

Die Daten auf deiner Festplatte sind dann aktueller als die in deinem Origin. Das ist völlig in Ordnung, denn neue Daten (= commits) laufen immer im Dreieck:

Upstream -> deine Festplatte -> dein Origin -> Upstream

Ich hoffe das war verständlich.

Peter

[4_Vs]

Hi Peter,

danke soweit ... vllt. finden wir in den nächsten Tagen mal Zeit für eine kurze Teamviewer-Sitzung oder ähnliches, denn irgendwie "platzt" bei mir der Knoten nicht, oder ich mache es richtig und weiß es nicht

Eilt aber nicht ... es gibt andere Prioritäten!

[following]

Es wäre ohnehin sinnvoller wenn der Entwicklungsleiter erst mal entscheidet, wie wir Git genau einsetzen; siehe [url=http://forum.geocaching-network.com/http://localhost//viewtopic.php?t=56.msg28942#msg28942]Offene Fragen[/url]. Ich habe hier - ausgehend von Roberts Überlegung, Forks zu verwenden, und Florians Link im erste Posting - einen sauberen, aber aufwändigen Git-Workflow beschrieben, der sich in großen Projekten bewährt hat. Es gibt einfachere und leichtverständlichere Varianten, die aber fehleranfälliger sind und das Projektmanagement verkomplizieren.

[following]

- Verwenden wir (standardmäßig) den Workflow mit eigenen Branches (http://forum.geocaching-network.com/http://localhost//viewtopic.php?p=28631#p28631)? Nach allem, was ich rausfinden konnte, ist das die beste Git-Arbeitsweise in größeren Projekten.

ja

-- Wenn ja: Wie ist mit Trivialänderungen umzugehen - reine Kommentare, Codeumformatierungen, Tippfehlerkorrekturen etc., die zu keiner bestimmten Aufgabe gehören?

Wenn es während der Arbeit an einer anderen Aufgabe auftritt: mit in den gleichen Branch packen und im Commit-Kommentar erläutern, was zusätzlich gemacht wurde. Ansonsten einen eigenen Branch dafür verwenden. ACHTUNG: Falls ihr mehrmals den gleichen Branch für diesen Zweck (wieder)verwendet, unbedingt ein

git pull --rebase upstream master

machen, bevor ihr es eincheckt! Gibt sonst unübersichtliche Querverbindung zu eurer letzten Änderung, wie ich sie z.B. heute produziert habe - die braune Linie hier: https://github.com/OpencachingDeutschla ... .0/network

- Verwenden wir (alternativ dazu) für Nichtentwickler die vereinfachte Methode ohne eigene Branches?

in Ausnahmefällen

- Benennung der Branches

siehe Beispiele: https://github.com/OpencachingDeutschla ... its/master

- Empfehlungen für die commit-Kommentare

eine Zusammenfassungszeile; zusätzliche Erläuterung wenn der Code (inkl. Kommentaren) nicht selbsterklärend ist

- deutsch oder englisch?

im Quelltext nach Möglichkeit Englisch

Bei den Branches und Commits ist es mir egal; was meint ihr?

- Arbeiten wir grundsätzlich sauber mit rebase, oder lassen wir auch merge bzw. pull zu, wenn es neue Commits des Entwicklers gibt die noch nicht im OpencachingDeutschland-Master angekommen sind?

Ersteres. Einfaches pull ist nur erlaubt, wenn man im lokalen master ist und sicher ist, dass dieser keine Änderungen enthält die im upstream/master fehlen. Also im Zweifelsfall besser gar nicht verwenden, sondern immer

Code: Alles auswählen

git fetch upstream
git rebase upstream/master

oder die Kurzform

Code: Alles auswählen

git pull --rebase upstream master

[following]

Um mich zu entlasten und die OC-Entwicklung auf mehr Schultern zu verteilen, habe ich mir jetzt noch die versprochene Git-Doku aus den Fingern gesaugt ...

https://www.opencaching.de/wiki/Main/OpencachingGit

... und eine neu Einführung für Entwickler geschrieben. Ich hoffe, die Git-Doku ist einigermaßen verständlich und erschlägt nicht zu sehr mit Details und Fachbegriffen. Ansonsten ggf. mehrmals lesen, nachfragen oder verbessern.

So, nun sollte niemand mehr eine Ausrede haben, um nicht mitzuprogrammieren. 

[mic@]

Erstmal DANKE für die tolle Anleitung.
Ich habe nur eine Frage: Warum steht bei der Beschreibung des Entwicklersystems folgendes:

# Die Downloadadressen für das VM-Image und den Dump erhältst du auf Anfrage vom Entwicklungsleiter oder von following.

? ? ? ?
Was ist so geheim an dieser VM, daß Du die Adresse nicht direkt reinschreiben magst?
Denn der oc-Code an sich ist ja nicht unter Verschluß, sondern per github einsehbar.

[following]

[quote="mic@"]
Was ist so geheim an dieser VM, daß Du die Adresse nicht direkt reinschreiben magst?
Denn der oc-Code an sich ist ja nicht unter Verschluß, sondern per github einsehbar.
[/quote]

Die VM enthält neben dem Code auch den Inhalt der opencaching.de-Datenbank, Stand Anfang 2010. Zwar sind alle persönlichen Daten und alle Logpasswörter gelöscht, aber die verfügbaren Informationen sind trotzdem deutlich umfangreicher als das, was per XML downloadbar ist. Solange die VM nur im Team verwendet wird und nicht ins Internet entkommt, ist das kein Problem ...

Von mir aus kann auch gerne der Download-Link ins Wiki. In dem alten Artikel von Tiger zum Entwicklersystem stand er nicht drin, sondern war durch "??????" ersetzt.

[mic@]

[quote="following"]Die VM enthält neben dem Code auch den Inhalt der opencaching.de-Datenbank, Stand Anfang 2010. [/quote]

Und was spricht dagegen, die VM auf einer Spieldatenbank mit Dummyusern und
Dummycaches aufzusetzen? Also alle Cachedaten und Benutzerdaten entfernen und
einfach mal für jeden Cachetyp ein Beispiel in der neuen Datenbank ablegen. Das
wäre dann klein, fein und verlinkbar 

[following]

Um realistisch testen zu können braucht es realistische Daten, sowohl von der Menge her als auch vom Inhalt.

Mod: sicherheitsrelevanten Teil des Postings vor Veröffentlichung entfernt

[4_Vs]

Mmmmh,

ich wollte gerade mit

Code: Alles auswählen

sudo -u apache git commit -am 'Danishop aus Liste entfernt'

eine Änderung in der team.tpl commiten und bekam folgende Fehlermeldung

Code: Alles auswählen

error: insufficient permission for adding an object to repository database .git/objects

error: Error building trees

Any suggestions?

Danke
Micha

[4_Vs]

[quote="4_Vs"]
Mmmmh,

ich wollte gerade mit

Code: Alles auswählen

sudo -u apache git commit -am 'Danishop aus Liste entfernt'

eine Änderung in der team.tpl commiten und bekam folgende Fehlermeldung

Code: Alles auswählen

error: insufficient permission for adding an object to repository database .git/objects

error: Error building trees

Any suggestions?

Danke
Micha
[/quote]
Mmmmh,

das war wieder ein Berechtigungsproblem im Verzeichnis .git

Aber jetzt bekomme ich die Sachen nicht mehr in mein orogon/master geschoben ... es ist zum verzweifeln ^^

[4_Vs]

Diese Fehlermeldung bekomme ich:

Code: Alles auswählen

git -c diff.mnemonicprefix=false -c core.quotepath=false push -v --tags origin master:master 
Pushing to http://github.com/4Vs/oc-server3
To http://github.com/4Vs/oc-server3
 = [up to date]      v3.0.0 -> v3.0.0
 = [up to date]      v3.0.1 -> v3.0.1
 = [up to date]      v3.0.1a -> v3.0.1a
 = [up to date]      v3.0.1b -> v3.0.1b
 ! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to 'http://github.com/4Vs/oc-server3'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes (e.g. 'git pull') before pushing again.  See the
'Note about fast-forwards' section of 'git push --help' for details.
Completed with errors, see above