Strategie für die Codeüberprüfung vor dem Zusammenführen zum Master aus Feature-Zweigen

Ich und mein Team verwenden Feature-Zweige (mit Git). Ich frage mich, welche Strategie für die Codeüberprüfung am besten geeignet ist, bevor sie zum Master zusammengeführt wird.

1. Ich checke einen neuen Zweig vom Master aus und nenne ihn fb_ # 1
2. Ich lege ein paar Mal fest und möchte es dann wieder zum Master zusammenführen
3. Vor dem Zusammenführen soll jemand eine Codeüberprüfung durchführen

Nun gibt es 2 Möglichkeiten:

1

1. Ich füge master zu fb_ # 1 zusammen ( nicht fb_ # 1 zu master), um es so aktuell wie möglich zu machen
2. Ein Teamkollege überprüft Änderungen zwischen dem Hauptkopf und dem Kopf von fb_ # 1
3. Wenn fb_ # 1 in Ordnung ist, führen wir fb_ # 1 zum Master zusammen
4. Vorteile: Kein veralteter Code in der Überprüfung
5. Nachteile: wenn jemand anderes etwas zwischen "1" zusammenfügt und 2." Seine Änderungen werden in der Rezension angezeigt, obwohl sie zu einer anderen Rezension gehören.

2nd

1. Ein Teamkollege überprüft Änderungen zwischen der Kasse (Git-Merge-Base-Master fb_ # 1) und dem Kopf fb_ # 1
2. Vorteile: Wir sehen genau, was sich während der Arbeit am Feature-Zweig geändert hat
3. Nachteile: In der Überprüfung wird möglicherweise veralteter Code angezeigt.

Welcher Weg ist Ihrer Meinung nach besser und warum ? Vielleicht gibt es einen anderen geeigneteren Ansatz?

Es gibt eine Variation Ihrer ersten Option:

1. Füge master zu fb_ # 1 (nicht fb_ # 1 zu master) zusammen, um es so aktuell wie möglich zu machen
2. Ein Teamkollege überprüft die Änderungen zwischen dem Master an dem Punkt, an dem Sie zusammengeführt haben, und dem Kopf von fb_ # 1
3. Wenn fb_ # 1 in Ordnung ist, führen wir fb_ # 1 zum Master zusammen
4. Überprüfen Sie schnell, ob die Zusammenführung in Ordnung ist

z.B.

... ma -- ... -- mm -- ... -- mf  <- master
      \            \         /
       f1 ... fn -- fm -----      <-- fb_#1

woher:

• ma ist der Vorfahr von master und fb_ # 1.
• fn ist die letzte Änderung in Ihrer Branche
• mm ist das Commit, das master / HEAD war, als Sie auf Ihrem Zweig zusammengeführt haben ( fm ).

Sie vergleichen also mm und fm in Ihrer ersten Überprüfung und überprüfen nach dem Zusammenführen von mf schnell , ob sich auf dem Master in den Schritten 1-3 nichts Wesentliches geändert hat. Dies scheint alle Vor-und Nachteile für die erste Überprüfung zu haben.

Dies setzt voraus, dass die Überprüfung im Vergleich zu der normalen Häufigkeit von Änderungen, die an den Master gesendet werden, schnell ist , sodass fm -> mf häufig ein schneller Vorlauf ist.

Wenn dies aus irgendeinem Grund nicht der Fall ist, werden die Nachteile nur von der anfänglichen Überprüfung zur Überprüfung nach dem Zusammenführen verschoben, und es ist möglicherweise einfacher, direkt auf den Master zusammenzuführen und dort eine einzelne Überprüfung durchzuführen.

3rd

• Sie bauen den Zweig auf dem Master neu auf, um ihn auf den neuesten Stand zu bringen und die Änderungen getrennt zu halten.

  Dies schafft eine neue Geschichte der Branche. Es handelt sich um neue Revisionen mit neuen IDs, die denselben Inhalt haben, jedoch vom neuesten Master abgeleitet werden und keine Verknüpfung zu den alten Revisionen herstellen. Die alten Revisionen sind in "reflog" weiterhin verfügbar, wenn Sie auf sie verweisen müssen, z. B. weil Sie einen Fehler bei der Konfliktlösung gefunden haben. Außerdem sind sie wertlos. Git schneidet das Reflog standardmäßig nach 3 Monaten ab und verwirft die alten Revisionen.

• Sie verwenden die interaktive Basis ( git rebase -iund git commit --amend), um die Änderungen neu zu ordnen, zu bearbeiten und zu bereinigen, sodass jede Änderung logisch abgeschlossen wird.

  Dadurch wird erneut eine neue Historie erstellt, diesmal mit dem zusätzlichen Vorteil, dass Sie die Änderungen so umstrukturieren können, dass sie bei der Überprüfung am sinnvollsten sind.

• Vorteile:

  • Kein veralteter Code in Überprüfung
  • Wir sehen genau, was sich während der Arbeit am Feature-Zweig geändert hat
• Nachteile:
  • ein bisschen mehr Arbeit
  • Sie müssen darauf achten, dass alles, was bereits zusammengeführt oder geteilt wurde und der Empfänger nicht erwartet, dass es zurückgespult wird, nicht wiederhergestellt wird.

Normalerweise bedeutet die zusätzliche Arbeit, dass Sie den Code zuerst gründlich selbst überprüfen und dies wird auch viele Probleme verursachen.

Dies ist, was Linux und Git tun. Und es ist nicht ungewöhnlich, dass in diesen Projekten Serien von 20 bis 25 Patches zur Überprüfung eingereicht und mehrmals umgeschrieben werden.

Eigentlich hat Linux es von Anfang an getan, als die Versionskontrolle der Wahl bei Tarballs und Patches lag. Als Linus viele Jahre später anfing, Git zu erstellen, war dies der Hauptgrund für die Implementierung des rebaseBefehls und seiner interaktiven Variante. Auch deswegen hat Git einen eigenen Begriff von Autor und Committer . Der Autor ist derjenige, der die Revision zuerst erstellt hat und derjenige, der sie zuletzt berührt hat. Da sowohl unter Linux als auch unter Git die Patches weiterhin per E-Mail übermittelt werden, sind die beiden fast nie dieselbe Person.

Es gibt tatsächlich eine dritte Möglichkeit - und höchstwahrscheinlich viele andere, da GIT eher eine Implementierung eines SCM-Frameworks als eine Implementierung einer SCM-Methodik ist. Diese dritte Möglichkeit basiert auf rebase.

Der rebaseGIT-Unterbefehl nimmt eine Reihe von Festschreibungen vor (normalerweise von Ihrem Verzweigungspunkt bis zur Spitze Ihres Zweigthemas topic) und spielt sie an einer anderen Stelle ab (normalerweise an der Spitze Ihres Integrationszweigs, z master. B. ). Der rebaseUnterbefehl erzeugt neue Commits, wodurch die Möglichkeit besteht, Commits in einer Form neu anzuordnen, die leichter zu überprüfen ist. Dies führt zu einer neuen Reihe von Festschreibungen, ähnlich der früheren topic, die jedoch an der Spitze des Integrationszweigs verankert zu sein scheinen. Dieser neue Zweig wird weiterhin topicvon GIT aufgerufen , sodass der alte Verweis verworfen wird. Ich beschrifte informell topic-0den ursprünglichen Zustand Ihrer Niederlassung topic-1und so weiter die verschiedenen Umgestaltungen.

Hier ist mein Vorschlag für Ihre topicBranche:

1. (Optionaler Schritt) Sie legen Ihren Zweig interaktiv topican seinem Verzweigungspunkt neu fest (siehe --fixupOption für commitund die -iund --autosquashOptionen für rebase), wodurch Sie die Möglichkeit haben, Ihre Commits auf eine Weise umzuschreiben, die leichter zu überprüfen ist. Dies führt zu einer Verzweigung topic-1.

2. Sie bauen Ihren Zweig "Topic" am Anfang Ihres Integrationszweigs neu auf, ähneln einer Zusammenführung, verschmutzen jedoch den Verlauf nicht mit einer Zusammenführung, die lediglich ein Software-Engineering-Artefakt ist. Dies führt zu einer Verzweigung topic-2.

3. Senden Sie es topic-2an einen Teamkollegen, der es gegen die Spitze von überprüft master.

4. Wenn topic-2es in Ordnung ist, dann füge es zum Master zusammen.

HINWEIS Die Verzweigungen - wobei Verzweigung sich auf den Festschreibungsbaum bezieht - werden von GIT alle gleich aufgerufen, sodass am Ende des Prozesses nur die Verzweigung topic-2einen Namen in GIT hat.

Vorteile:

• Kein veralteter Code in Überprüfung.
• Keine fälschlichen "Foreign Merges" -Rezensionen (das Phänomen, das Sie in 1. beschrieben haben).
• Gelegenheit, Commits sauber umzuschreiben.

Nachteile:

• Anstelle eines Zweiges topic-0, gibt es drei Zweige Artefakte topic-0, topic-1und topic-2die erzeugt werden , in den Baum zu begehen. (Obwohl zu jeder Zeit nur einer von ihnen einen Namen in GIT hat.)

In Ihrem ersten Szenario «wenn jemand etwas zwischen" 1 "zusammengeführt hat. und "2." bezieht sich auf die Zeitspanne zwischen der Erstellung des Verzweigungspunkts und dem Zeitpunkt, zu dem Sie sich für eine Zusammenführung entscheiden. In diesem Szenario «wenn jemand etwas zwischen" 1. " und "2." bezieht sich auf die Zeitspanne zwischen der Basiswiederherstellung und der Zusammenführung, die normalerweise sehr kurz ist. So können Sie in dem von mir masterbereitgestellten Szenario den Zweig für die Zeit der Zusammenführung «sperren», ohne Ihren Arbeitsablauf wesentlich zu stören, während dies im ersten Szenario unpraktisch ist.

Wenn Sie systematische Codeüberprüfungen durchführen, ist es wahrscheinlich eine gute Idee, die Commits in angemessener Weise neu anzuordnen (optionaler Schritt).

Das Verwalten der Artefakte zwischen Verzweigungen ist nur dann schwierig, wenn Sie sie für mehrere Repositorys freigeben.