it-swarm.com.de

Best Practices für das Verzweigen und Markieren von Git

Ich lerne gerade, Git zu benutzen, indem ich Pro Git lese. Im Moment lerne ich über Verzweigungen und Tags. Meine Frage ist, wann ich einen Zweig verwenden soll und wann ich ein Tag verwenden soll.

Angenommen, ich erstelle einen Zweig für Version 1.1 eines Projekts. Sollte ich nach Abschluss und Veröffentlichung dieser Version den Zweig verlassen, um die Release-Version zu markieren? Oder sollte ich ein Tag hinzufügen? Wenn ich ein Tag hinzufüge, sollte ich den Versionszweig löschen (vorausgesetzt, er wird mit dem Master oder einem anderen Zweig zusammengeführt)?

149
Code-Guru

Kurz gesagt: Best Practice ist Verzweigen, häufig zusammenführen und immer synchron halten .

Es gibt ziemlich klare Konventionen, wie Sie Ihren Code in einem vom Hauptzweig getrennten Zweig aufbewahren können:

  1. Sie sind dabei, größere oder störende Änderungen vorzunehmen
  2. Sie sind dabei, einige Änderungen vorzunehmen, die möglicherweise nicht verwendet werden
  3. Sie möchten mit etwas experimentieren, von dem Sie nicht sicher sind, ob es funktioniert
  4. Wenn Sie aufgefordert werden, sich zu verzweigen, haben andere möglicherweise etwas, das sie im Master tun müssen

Als Faustregel gilt, dass Sie nach dem Verzweigen mit dem Hauptzweig synchron bleiben sollten. Denn irgendwann müssen Sie es wieder zum Master zusammenführen. Um ein großes, kompliziertes Durcheinander von Konflikten beim Zurückführen zu vermeiden, sollten Sie häufig festlegen, häufig zusammenführen.

Gute Praktiken zu befolgen

Ein erfolgreiches Git-Verzweigungsmodell von Vincent Driessen hat gute Vorschläge. Wenn dieses Verzweigungsmodell Sie anspricht, berücksichtigen Sie das Flusserweiterung zu git . Andere haben über Flow kommentiert .

Tagging-Praktiken

Wie Sie bereits wissen, gibt Git Ihnen Commit-IDs wie 1.0-2-g1ab3183, aber das sind keine Tags! Das Taggen erfolgt mit dem Git-Tag, und die Tags, die mit dem Git-Tag erstellt werden, sind die Basis für die Commit-IDs, die von Git beschrieben erstellt werden. Mit anderen Worten, in Git markieren Sie keine Zweige. Sie markieren Commits. Es ist richtig zu sagen, dass das Tag nur ein kommentierter Zeiger auf ein Commit ist.

Schauen wir uns ein praktisches Beispiel an, das es demonstriert hat:

/- [v1.0] 
 V 
 ---. ---. --- .--- S ---.--- A <- - Master 
\
\-.--- B <- Test 

Lassen Sie uns 'S' festschreiben, wobei das Tag 'v1.0' darauf hinweist. Dieses Commit erfolgt sowohl im Zweig 'Master' als auch im Zweig 'Test'. Wenn Sie " git description " über Commit 'A' (oben im 'Master'-Zweig) ausführen, erhalten Sie so etwas wie v1.0-2-g9c116e9. Wenn Sie "git description" über Commit 'A' (auch bekannt als 'Test'-Zweig) ausführen, erhalten Sie so etwas wie v1.0-2-g3f55e41, das ist bei der Standardkonfiguration von git-description der Fall. Beachten Sie, dass dieses Ergebnis etwas anders ist. v1.0-2-g9c116e9 bedeutet, dass wir mit der verkürzten SHA-1-ID von 9c116e9, 2 Commits nach Tag v1.0. Es gibt kein Tag v1.0-2!

Wenn Sie möchten, dass Ihr Tag nur im Zweig 'master' angezeigt wird, können Sie nach dem Verzweigungspunkt des Zweigs 'test' ein neues Commit erstellen (z. B. nur die Standard-/Fallback-Versionsinformationen in GIT-VERSION-FILE aktualisieren). Wenn Sie Commits im 'Test'-Zweig mit z. 'v1.0.3` wäre nur ab' test 'sichtbar.

Verweise

Ich habe viele, viele nützliche Blogs und Beiträge gefunden, aus denen ich lernen kann. Diejenigen, die professionell illustriert werden, sind jedoch selten. Daher möchte ich einen Beitrag empfehlen - Ein erfolgreiches Git-Verzweigungsmodell von @nvie. Ich habe seine Illustration ausgeliehen :)

enter image description here

167
Yusubov

Ein Zweig wird verwendet, wenn Sie zwei verschiedene Versionen des Repositorys gleichzeitig haben. Ein Tag ist eine Möglichkeit, einen Zeitpunkt in Ihrem Repository zu markieren.

Sie sollten ein Tag hinzufügen, um eine freigegebene Version zu markieren. Wenn Sie dann Fehlerbehebungen für diese Version vornehmen müssen, erstellen Sie einen Zweig am Tag.

Sie möchten nur Zweige löschen, die wieder in den HEAD [oder einen anderen Zweig] zusammengeführt wurden.

37
gam3