Wenn ein Feature von experimentell zu stabil übergeht, "graduiert" es auch zwischen den entsprechenden Branches der Software. git.git verwendet die folgenden Integrations-Branches

Es gibt einen vierten offiziellen Branch, der etwas anders verwendet wird

Jeder der vier Branches ist normalerweise ein direkter Nachfahre des darüber liegenden.

Konzeptionell gelangt das Feature in einen instabilen Branch (normalerweise next oder seen) und "graduiert" zu master für die nächste Veröffentlichung, sobald es als stabil genug erachtet wird.

Die oben diskutierte "absteigende Graduierung" kann jedoch nicht durch tatsächliches absteigendes Mergen erfolgen, da dies alle Änderungen auf dem instabilen Branch in den stabilen mergen würde. Daher gilt:

Dies ergibt einen sehr kontrollierten Fluss von Korrekturen. Wenn Sie feststellen, dass Sie eine Korrektur in z. B. master angewendet haben, die auch in maint benötigt wird, müssen Sie sie (mit git-cherry-pick[1]) nach unten cherry-picken. Dies wird ein paar Mal vorkommen und ist kein Grund zur Sorge, es sei denn, Sie tun es sehr häufig.

Jedes nicht triviale Feature erfordert mehrere Patches zur Implementierung und kann im Laufe seines Lebens zusätzliche Fehlerbehebungen oder Verbesserungen erhalten.

Alles direkt auf den Integrations-Branches zu committen, führt zu vielen Problemen: Schlechte Commits können nicht rückgängig gemacht werden, daher müssen sie einzeln zurückgesetzt werden, was verwirrende Historien und weiteres Fehlerpotenzial erzeugt, wenn Sie vergessen, einen Teil einer Änderungsgruppe zurückzusetzen. Paralleles Arbeiten vermischt die Änderungen und schafft weitere Verwirrung.

Die Verwendung von "Topic-Branches" löst diese Probleme. Der Name ist ziemlich selbsterklärend, mit einer Einschränkung, die sich aus der obigen Regel "Nach oben mergen" ergibt

Viele Dinge können dann sehr natürlich erfolgen

Beachten Sie, dass der letzte Punkt mit den beiden anderen kollidiert: Ein Thema, das bereits woanders gemergt wurde, sollte nicht neu basisiert werden. Siehe den Abschnitt über die WIEDERHERSTELLUNG NACH UPSTREAM REBASE in git-rebase[1].

Wir möchten darauf hinweisen, dass das "gewohnheitsmäßige" (regelmäßige ohne wirklichen Grund) Mergen eines Integrations-Branches in Ihre Themen - und damit auch das regelmäßige Mergen von etwas Upstream in etwas Downstream - verpönt ist.

Andernfalls enthält das Thema, zu dem gemergt wurde, plötzlich mehr als eine einzelne (gut getrennte) Änderung. Die vielen daraus resultierenden kleinen Merges werden die Historie stark verunreinigen. Jeder, der später die Historie einer Datei untersucht, muss herausfinden, ob der Merge das sich entwickelnde Thema beeinflusst hat. Ein Upstream könnte sogar versehentlich in einen "stabileren" Branch gemergt werden. Und so weiter.

Wenn Sie dem letzten Absatz gefolgt sind, werden Sie nun viele kleine Topic-Branches haben und sich gelegentlich fragen, wie sie interagieren. Vielleicht funktioniert das Ergebnis des Mergens sie sogar nicht? Aber andererseits wollen wir vermeiden, sie irgendwohin "stabiles" zu mergen, da solche Merges nicht einfach rückgängig gemacht werden können.

Die Lösung ist natürlich, einen Merge zu erstellen, den wir rückgängig machen können: in einen Wegwerf-Branch mergen.

Wenn Sie sehr klar machen, dass dieser Branch direkt nach dem Testen gelöscht wird, können Sie diesen Branch sogar veröffentlichen, zum Beispiel um den Testern die Möglichkeit zu geben, damit zu arbeiten, oder anderen Entwicklern die Möglichkeit zu geben zu sehen, ob ihre laufende Arbeit kompatibel sein wird. git.git hat einen solchen offiziellen Wegwerf-Integrations-Branch namens seen.

Unter der Annahme, dass Sie den oben diskutierten Merge-Ansatz verwenden, müssen Sie bei der Veröffentlichung Ihres Projekts zusätzliche Branch-Management-Arbeiten durchführen.

Eine Feature-Veröffentlichung wird vom master-Branch erstellt, da master die Commits verfolgt, die in die nächste Feature-Veröffentlichung eingehen sollen.

Der master-Branch soll eine Obermenge von maint sein. Wenn diese Bedingung nicht erfüllt ist, dann enthält maint einige Commits, die nicht in master enthalten sind. Die von diesen Commits dargestellten Korrekturen werden daher nicht in Ihre Feature-Veröffentlichung aufgenommen.

Um zu überprüfen, ob master tatsächlich eine Obermenge von maint ist, verwenden Sie git log

Dieser Befehl sollte keine Commits auflisten. Andernfalls wechseln Sie zu master und mergen maint hinein.

Nun können Sie mit der Erstellung der Feature-Veröffentlichung fortfahren. Wenden Sie ein Tag auf die Spitze von master an, das die Veröffentlichungsversion angibt

Sie müssen das neue Tag an einen öffentlichen Git-Server pushen (siehe "VERTEILTE WORKFLOWS" unten). Dies macht das Tag für andere verfügbar, die Ihr Projekt verfolgen. Der Push kann auch einen Post-Update-Hook auslösen, um Release-bezogene Elemente wie das Erstellen von Release-Tarballs und vorformatierten Dokumentationsseiten durchzuführen.

Ähnlich verhält es sich bei einer Wartungsversion, maint verfolgt die zu veröffentlichenden Commits. Daher taggen und pushen Sie in den obigen Schritten einfach maint anstelle von master.

Nach einer Feature-Veröffentlichung müssen Sie Ihre Wartungs-Branches verwalten.

Wenn Sie weiterhin Wartungs-Fixes für die vor der letzten Feature-Veröffentlichung erstellte Feature-Veröffentlichung veröffentlichen möchten, müssen Sie einen weiteren Branch erstellen, um die Commits für diese vorherige Veröffentlichung zu verfolgen.

Dazu wird der aktuelle Wartungs-Branch auf einen anderen Branch kopiert, der mit der vorherigen Versionsnummer benannt ist (z. B. maint-X.Y.(Z-1), wobei X.Y.Z die aktuelle Veröffentlichung ist).

Der maint-Branch sollte nun auf den neu veröffentlichten Code fast-forwarded werden, damit Wartungs-Fixes für die aktuelle Veröffentlichung verfolgt werden können.

Wenn der Merge fehlschlägt, weil es sich nicht um einen Fast-Forward handelt, ist es möglich, dass einige Fixes auf maint in der Feature-Veröffentlichung übersehen wurden. Dies geschieht nicht, wenn der Inhalt der Branches wie im vorherigen Abschnitt beschrieben überprüft wurde.

Nach einer Feature-Veröffentlichung kann der Integrations-Branch next optional zurückgespult und vom Tip von master unter Verwendung der verbleibenden Themen auf next neu aufgebaut werden.

Der Vorteil davon ist, dass die Historie von next sauber sein wird. Zum Beispiel waren einige Themen, die in next gemergt wurden, anfangs vielversprechend, erwiesen sich aber später als unerwünscht oder verfrüht. In diesem Fall wird das Thema aus next zurückgesetzt, aber die Tatsache bleibt in der Historie, dass es einmal gemergt und zurückgesetzt wurde. Durch die Neuerstellung von next erhalten andere Inkarnationen solcher Themen eine saubere Weste, um es erneut zu versuchen, und eine Feature-Veröffentlichung ist ein guter Zeitpunkt dafür.

Wenn Sie dies tun, sollten Sie eine öffentliche Ankündigung machen, die besagt, dass next zurückgespult und neu aufgebaut wurde.

Der gleiche Zurückspul- und Neuaufbauprozess kann für seen erfolgen. Eine öffentliche Ankündigung ist nicht erforderlich, da seen ein Wegwerf-Branch ist, wie oben beschrieben.

Der Merge-Workflow funktioniert, indem Branches zwischen Upstream und Downstream kopiert werden. Upstream kann Beiträge in die offizielle Historie mergen; Downstream basieren ihre Arbeit auf der offiziellen Historie.

Es gibt drei Hauptwerkzeuge, die dafür verwendet werden können

Beachten Sie den letzten Punkt. Verwenden Sie git pull nicht, es sei denn, Sie möchten tatsächlich den Remote-Branch mergen.

Änderungen herauszubekommen ist einfach

Sie müssen die Leute immer noch auf andere Weise informieren, z. B. per E-Mail. (Git stellt git-request-pull[1] zur Verfügung, um vorformatierte Pull-Anfragen an Upstream-Maintainer zu senden, um diese Aufgabe zu vereinfachen.)

Wenn Sie nur die neuesten Kopien der Integrations-Branches erhalten möchten, ist es auch einfach, auf dem neuesten Stand zu bleiben

Verzweigen Sie dann einfach Ihre Topic-Branches von den stabilen Remotes, wie oben erklärt.

Wenn Sie ein Maintainer sind und die Topic-Branches anderer Leute in die Integrations-Branches mergen möchten, senden sie Ihnen in der Regel eine entsprechende Anfrage per E-Mail. Eine solche Anfrage sieht so aus:

In diesem Fall kann git pull das fetch und merge in einem Schritt durchführen, wie folgt.

Gelegentlich kann der Maintainer Merge-Konflikte erhalten, wenn er versucht, Änderungen von Downstream zu ziehen. In diesem Fall kann er Downstream bitten, den Merge durchzuführen und die Konflikte selbst zu lösen (vielleicht weiß er besser, wie er sie lösen kann). Dies ist einer der seltenen Fälle, in denen Downstream von Upstream mergen sollte.

Wenn Sie ein Mitwirkender sind, der Änderungen in Form von E-Mails an Upstream sendet, sollten Sie wie gewohnt Topic-Branches verwenden (siehe oben). Verwenden Sie dann git-format-patch[1], um die entsprechenden E-Mails zu generieren (sehr empfehlenswert gegenüber manueller Formatierung, da dies das Leben des Maintainers erleichtert).

Siehe die Manpages git-format-patch[1] und git-send-email[1] für weitere Nutzungshinweise.

Wenn Ihnen der Maintainer mitteilt, dass Ihr Patch nicht mehr auf das aktuelle Upstream angewendet werden kann, müssen Sie Ihr Thema neu basisieren (Sie können keinen Merge verwenden, da Sie keine Merges format-patchen können)

Sie können die Konflikte dann während des Rebase beheben. Vermutlich haben Sie Ihr Thema nicht anderweitig als per E-Mail veröffentlicht, so dass das Rebasieren kein Problem darstellt.

Wenn Sie eine solche Patch-Serie erhalten (als Maintainer oder vielleicht als Leser der Mailingliste, an die sie gesendet wurde), speichern Sie die E-Mails in Dateien, erstellen Sie einen neuen Topic-Branch und verwenden Sie git am, um die Commits zu importieren.

Eine erwähnenswerte Funktion ist der Drei-Wege-Merge, der helfen kann, wenn Sie Konflikte erhalten: git am -3 verwendet Indexinformationen aus den Patches, um die Merge-Basis zu ermitteln. Siehe git-am[1] für weitere Optionen.