Verwendung von Git, um alte Versionen zu pflegen

Question

Ich habe auf Git-Verzweigung Workflows gelesen und es scheint eine Annahme, dass Zweige gibt es für Entwicklungszwecke mit allem schließlich wieder in Master zusammengeführt werden. Ich kann nicht viel Diskussion über die Verwendung von lang laufenden Zweigen für die Wartung von älteren Versionen finden.

Zum Beispiel, hier ist, wie mein Workflow in SVN funktioniert (basierend auf dem "Tofu" Modell). Nehmen wir an, die neueste veröffentlichte Version ist 4.1, aber ich unterstütze auch die Versionen 4.0, 3.5 und 3.6, daher gibt es für jede von diesen einen Wartungszweig. Trunk wird für Features verwendet, die erst ab 4.2 veröffentlicht werden. Jetzt sagen Sie, dass ein Kunde einen Bugfix zu Version 3.6 benötigt. Ich werde das Update in meinen Wartungszweig von 3.6 machen und eine neue Wartungsfreigabe machen (aus Gründen der Argumentation, 3.6.22).

An diesem Punkt wird der Fix nach unten in 4.0 zusammengeführt und von dort zu 4.1, 4.2 und Stamm und von dort in alle Entwicklungszweige aus Stamm. Beachten Sie, dass es sich hierbei nicht um eine Auswahl handelt. Es ist eine normale SVN automatische Zusammenführung.

Wenn die Behebung nicht trivial ist, können wir einen Dev-Zweig aus dem 3.6-Release-Zweig machen und ihn dann auf die normale Weise wieder integrieren, bevor wir ihn freigeben. Wenn die Zusammenführung zu 4.1 nicht-trivial ist, können wir einen Entwicklungszweig von 4.1 erstellen, um ihn dann in 4.1 zu integrieren und dann wieder zu integrieren, wenn wir mit der Zusammenführung zufrieden sind.

Wenn wir Release-Version 4.2 werden wir eine Wartung Zweig für das in gleicher Weise abzweigen und Rumpf wird sich laufend 4.3 Arbeit

Soll ich (oder auch ich kann) verwenden, um genau den gleichen Workflow in git, Oder ist das "alte Hut" traditionelles SVN-Denken, das neu überdacht werden muss?

Answer 1

Verzweigungsstrategien ändern sich nicht wirklich, abhängig von der Versionskontrolltechnologie. Was Sie beschrieben haben, klingt nach einem normalen Branching-Workflow für ein Live-Produkt. Was sich beim Verschieben von einem anderen Tool wie SVN in Git ändern würde, ist die Kosten des Erstellens und Pflegens einer Verzweigung. In Git ist die Verzweigung extrem günstig. Ein Zweig in Git ist im Grunde nur ein Zeiger auf ein Commit. So wären beispielsweise die Kosten für die Erstellung eines Wartungszweigs, der nur wenige Commits enthält, inkrementell sehr klein. Dies ist möglicherweise bei einem Tool wie SVN nicht der Fall, wo möglicherweise eine Kopie oder jede Datei im Projekt erstellt werden muss.