3.4 Git Branching - Branching Workflows

Da Git eine einfache Drei-Wege-Zusammenführung verwendet, ist das mehrfache Zusammenführen eines Branches in einen anderen über einen langen Zeitraum im Allgemeinen einfach durchzuführen. Das bedeutet, Sie können mehrere Branches haben, die immer geöffnet sind und die Sie für verschiedene Phasen Ihres Entwicklungszyklus verwenden. Sie können regelmäßig von einigen dieser Branches in andere zusammenführen.

Viele Git-Entwickler haben einen Workflow, der diesen Ansatz verfolgt, zum Beispiel indem sie nur vollständig stabilen Code in ihrem master-Branch haben – möglicherweise nur Code, der veröffentlicht wurde oder veröffentlicht wird. Sie haben einen weiteren parallelen Branch namens develop oder next, von dem aus sie arbeiten oder den sie zur Überprüfung der Stabilität verwenden – er ist nicht unbedingt immer stabil, aber wann immer er einen stabilen Zustand erreicht, kann er in master zusammengeführt werden. Er wird verwendet, um Topic Branches (kurzlebige Branches, wie Ihr früherer iss53-Branch) zu integrieren, wenn sie bereit sind, um sicherzustellen, dass sie alle Tests bestehen und keine Fehler einführen.

Tatsächlich sprechen wir über Zeiger, die sich auf der Linie der von Ihnen erstellten Commits nach oben bewegen. Die stabilen Branches befinden sich weiter unten in Ihrer Commit-Historie und die Bleeding-Edge-Branches weiter oben in der Historie.

Es ist im Allgemeinen einfacher, sie als Arbeits-Silos zu betrachten, in denen Commits in ein stabileres Silo übergehen, wenn sie vollständig getestet sind.

Sie können dies für mehrere Stabilitätsstufen fortsetzen. Einige größere Projekte haben auch einen proposed- oder pu-Branch (proposed updates), der integrierte Branches enthält, die möglicherweise noch nicht für den next- oder master-Branch bereit sind. Die Idee ist, dass Ihre Branches verschiedene Stabilitätsstufen haben; wenn sie ein stabileres Niveau erreichen, werden sie in den übergeordneten Branch zusammengeführt. Wiederum ist es nicht notwendig, mehrere langfristige Branches zu haben, aber es ist oft hilfreich, insbesondere wenn Sie mit sehr großen oder komplexen Projekten arbeiten.

Topic Branches sind jedoch bei Projekten jeder Größe nützlich. Ein Topic Branch ist ein kurzlebiger Branch, den Sie für eine einzelne bestimmte Funktion oder zugehörige Arbeit erstellen und verwenden. Dies ist etwas, das Sie wahrscheinlich noch nie mit einem VCS gemacht haben, da das Erstellen und Zusammenführen von Branches im Allgemeinen zu teuer ist. Aber in Git ist es üblich, mehrmals täglich Branches zu erstellen, daran zu arbeiten, sie zusammenzuführen und zu löschen.

Sie haben dies im letzten Abschnitt mit den iss53- und hotfix-Branches gesehen, die Sie erstellt haben. Sie haben ein paar Commits darauf gemacht und sie direkt nach dem Zusammenführen in Ihren Haupt-Branch gelöscht. Diese Technik ermöglicht es Ihnen, den Kontext schnell und vollständig zu wechseln – da Ihre Arbeit in Silos getrennt ist, in denen alle Änderungen in diesem Branch mit diesem Thema zu tun haben, ist es einfacher zu sehen, was während der Code-Überprüfung usw. passiert ist. Sie können die Änderungen dort für Minuten, Tage oder Monate aufbewahren und sie zusammenführen, wenn sie bereit sind, unabhängig von der Reihenfolge, in der sie erstellt oder bearbeitet wurden.

Betrachten Sie ein Beispiel, bei dem Sie einige Arbeiten durchführen (auf master), für ein Issue abzweigen (iss91), etwas daran arbeiten, von dem zweiten Branch abzweigen, um einen anderen Weg zur Behandlung desselben Dings auszuprobieren (iss91v2), zu Ihrem master-Branch zurückkehren und dort eine Weile arbeiten und dann dort abzweigen, um etwas zu tun, von dem Sie nicht sicher sind, ob es eine gute Idee ist (dumbidea-Branch). Ihre Commit-Historie würde ungefähr so aussehen

Nun, sagen wir, Sie entscheiden, dass Ihnen die zweite Lösung für Ihr Problem am besten gefällt (iss91v2); und Sie haben den dumbidea-Branch Ihren Kollegen gezeigt, und er erweist sich als genial. Sie können den ursprünglichen iss91-Branch wegwerfen (und die Commits C5 und C6 verlieren) und die anderen beiden zusammenführen. Ihre Historie sieht dann so aus

Wir werden in Distributed Git detaillierter auf die verschiedenen möglichen Workflows für Ihr Git-Projekt eingehen. Lesen Sie daher dieses Kapitel, bevor Sie entscheiden, welches Branching-Schema Ihr nächstes Projekt verwenden wird.

Es ist wichtig, sich daran zu erinnern, dass diese Branches vollständig lokal sind, wenn Sie all dies tun. Wenn Sie verzweigen und zusammenführen, geschieht alles nur in Ihrem Git-Repository – es gibt keine Kommunikation mit dem Server.