it-swarm.com.de

Codeüberprüfung mit Git-Flow und Github

Mit normalem Git und Github kann ich eine Codeüberprüfung durchführen, indem ich einfach eine Pull-Anforderung des Feature-Zweigs, an dem ich arbeite, an den Master-Zweig erstelle. Wie würde ich Codeüberprüfungen mit git-flow durchführen? Bei Workflows wie "Git Flow Feature Finish" bin ich verwirrt darüber, wo die Codeüberprüfung tatsächlich stattfindet und wie Git-Flow oder Git diese Überprüfung erleichtern können.

43
AdamT

Wir sind kürzlich auf genau dieses Problem gestoßen. Wir mögen Git Flow wirklich, da es eine gute Ebene der Semantik verwendet (mit derselben Ebene, die Sie in der Teamdiskussion verwenden: "Ich starte Feature A" mehr als "Ich werde einen Zweig erstellen, ihn auschecken") Git ist sehr "Implementierungs" -Ebene (was auch gut und nützlich ist, aber anders).

Das Problem, das wir haben, ist mit git feature finish, da der Zweig in die Entwicklung zusammengeführt wird, während eine Pull-Anfrage gesendet werden soll und (dies ist wichtig) vom Prüfer zusammengeführt, nicht der Committer, um die Teamverantwortung zu betonen.

Unsere aktuelle Lösung:

  1. Jemand verwendet Git Flow, um einen Feature-Zweig zu erstellen
  2. Wenn er fertig ist, erstellt er eine Pull-Anfrage (mit Github).
  3. Die Überprüfung erfolgt mit potenziellen zusätzlichen Verpflichtungen
  4. Die Pull-Anfrage wird zusammengeführt mit GitHub vom Reviewer.
  5. Das Ende des Git-Flow-Features ist nicht abgeschlossen (da der Zweig bereits zusammengeführt wurde).

Dies steht im Einklang mit unserer Praxis, mit dem Nachteil, dass der Zweig selbst gelöscht werden muss (da wir kein Flow-Finish durchführen). Unser nächster Schritt wird wahrscheinlich darin bestehen, einige Teile des Git-Flusses neu zu implementieren (da es hauptsächlich um das Verketten von Git-Befehlen geht), um dies zu berücksichtigen (wobei der "Reinigungsteil" des Finishs ohne Zusammenführung erfolgt).

29
Martin

Der Prozess, mit dem das Team, mit dem ich arbeite, verwendet wird, ist wie folgt:

  1. Erstellen Sie einen Feature-Zweig: git flow feature start module_1
  2. Der Code wird im Feature-Zweig aktualisiert
  3. Wenn Änderungen festgeschrieben werden, werden sie an GitHub übertragen (oder, falls gewünscht, einmal am Ende)
  4. Wenn das Feature abgeschlossen ist, wird in GitHub eine Pull-Anfrage geöffnet, die develop und den Feature-Zweig module_1 Vergleicht.
  5. Das Team überprüft die Pull-Anfrage und macht Kommentare
  6. Alle Änderungen aus der Pull-Anforderung werden am Feature-Zweig vorgenommen
  7. Sobald alle Änderungen in den Feature-Zweig übernommen wurden, ist der Feature-Zweig abgeschlossen: git flow feature finish module_1
  8. Der Zweig develop wird an GitHub gesendet (GitHub markiert die Pull-Anforderung in diesem Fall automatisch als geschlossen/zusammengeführt).

Normalerweise wird der gesamte Vorgang vom ursprünglichen Autor ausgeführt, dies ist jedoch nicht erforderlich. Jeder in unserem Team kann jederzeit in diesen Prozess einsteigen und ihn abholen. Sie müssen lediglich den Feature-Zweig auschecken und mit dem Vorgang fortfahren. Wer git flow feature finish module_1 Führt, hat den Luxus, dass sein lokaler Feature-Zweig gelöscht wird, aber jeder andere, der den Zweig mit ausgecheckt hat, muss dies manuell tun, wenn er etwas wie git branch -D feature/module_1 Verwenden möchte.

Für Hotfixes verwenden wir einen ähnlichen Ansatz und erstellen die Pull-Anforderung in GitHub, bevor wir den Hotfix beenden.

17
brainimus

Hier ist ein weiterer Vorschlag.

  1. Führen Sie den regulären Git-Flow-Prozess aus, um ein Feature erstellen, aber beenden oder führen Sie es nicht zusammen.
  2. Pull-Anfrage erstellen, aber nicht zusammenführen. Warten Sie, bis der Genehmigende einen Kommentar hinterlassen hat. Der Kommentar ist das Zeichen der Zustimmung.
  3. Mach das Git Flow Finish. (Entweder der Genehmigende oder der Entwickler können dies tun, je nachdem, was das Team vereinbart hat.) Die Pull-Anforderung wird auf Github als zusammengeführt markiert. Sie müssen den Zweig in Origin noch löschen.
4
Peet Brits

Wenn Sie Codeüberprüfungen durchführen, gehe ich davon aus, dass Sie über ein zentrales Repository verfügen, das den "offiziellen" Code enthält. Entwickler ziehen aus diesem zentralen Repository und pushen es.

Wenn Sie Gerrit verwenden, wird Gerrit selbst zum zentralen Repository (es verfügt über integrierte SSH- und HTTP-Server, mit denen Benutzer im Grunde auf die gleiche Weise mit ihnen interagieren können, wie sie es bereits sind). Bei Verwendung von Gerrit wird der Workflow wie folgt:

  1. Der Entwickler nimmt Änderungen in jedem Zweig vor und schreibt diese lokal fest.
  2. Der Entwickler überträgt diese Änderungen an Gerrit.
  3. Gerrit erstellt Überprüfungselemente, die von anderen überprüft werden können.
  4. Kollegen überprüfen den Code, machen Kommentare und akzeptieren oder lehnen das Commit ab.
  5. Wenn das Commit akzeptiert wird, und dann stellt Gerrit diese Änderungen anderen zur Verfügung, um sie aus dem Zweig zu ziehen.

Bei Verwendung eines zentralen Repositorys können andere Entwickler die übermittelten Änderungen nach Schritt 2 sehen. Gerrit führt den Workflow für die Codeüberprüfung ein, sodass andere Entwickler die übermittelten Änderungen erst nach Schritt 5 sehen.

Dies funktioniert gut mit Git-Flow (oder einem anderen Verzweigungsschema), da Gerrit die Überprüfung von Änderungen unterstützt, die an einem Zweig vorgenommen wurden.

3
Greg Hewgill