Unsere Software-Produktlinie erfordert die gleichzeitige Entwicklung und Pflege mehrerer Softwareversionen. Wir sind relative Git-Neulinge und haben kürzlich Git Flow eingeführt, um unsere Vorteile zu nutzenDriessens Verzweigungsmodell. Wir haben ein sehr kleines Software-Team mit wenigen engagierten Entwicklern (wir alle tragen viele Hüte) und keinem "Integrationsguru".

Viele Suchanfragen haben wenig konkrete Ratschläge ergeben, wie Git und Git Flow an unsere Bedürfnisse angepasst werden können. Es hat sich herausgestellt, dass Git Flow nicht für die gleichzeitige Unterstützung mehrerer Versionen geeignet ist. Einverwandte Diskussion über SO hat Antworten, die angeben, dass separate Filialnamen verwendet werden müssen, um die Historien der einzelnen Versionen zu verfolgen. Diese und verwandte Strategien eliminieren Git Flow, sofern es nicht geändert wird. Sehen Sie sich die oben genannten Teameinschränkungen an, um herauszufinden, warum dies für uns nicht praktikabel ist.

Die entscheidende Frage ist, wie sich andere als ein guter Ansatz erwiesen haben, um das Verzweigungsmodell von Driessen so eng wie möglich zu implementieren und gleichzeitig mehrere Release-Lines zu unterstützen.

AKTUALISIERUNG:

Wenn Sie die folgenden Antworten (insbesondere @Rasmus ') mit gezielterer Suche und internen Diskussionen zu einigen Optionen kombinieren, erhalten Sie die folgende Lösung, die wir implementieren und die ich als einen Ansatz anbiete, der für ähnliche Teams unter ähnlichen Bedingungen relevant sein kann.

Git Flow wird nicht weiter verwendet. Stattdessen wenden wir Driessens Modell auf jede einzelne Release-Zeile in einem Repo an, indem wir jedem Filialnamen die beabsichtigte Release-Zeichenfolge voranstellen, z.

r1.5/develop

Alle Versionen eines Projekts sind im Git-Repository enthalten. Das Starten einer neuen Projektversion besteht darin, eine kleine Menge neuer, langlebiger Zweige zu erstellen, denen die Release-Zeichenfolge vorangestellt ist (z.r1.6/develop und in unserem Fallr1.6/release; Neinmaster mit seiner Implikation des einzelnen aktuellen guten baubaren Zustands).

Wir richten ein zentrales öffentliches Repository pro Projekt auf einem Server ein, auf dem Code über das lokale Repository ausgetauscht werden kannremote links. Ein Push in dieses Repository bedeutet, dass Code für andere Benutzer verfügbar ist. ZusammenführenRX.Y/develop hinein und dann drücke dieRX.Y/release Verzweigung bezeichnet Code, der für die Freigabe vorgesehen ist.feature, hotfixet. al. Zweige werden ähnlich behandelt. Der Verlauf des Zusammenführens / Festschreibens von Zweigen für eine bestimmte Release-Zeile ist übersichtlich und verständlich. Wir wollen nicht, dass die typische Git-Distributed-Repo-Strategie zugunsten der Vermeidung der Komplexität beim Zusammenführen von Repos angewendet wird, deren Struktur im Laufe der Zeit wahrscheinlich voneinander abweicht.

In einigen Git-GUIs (wie z. B. SourceTree) wird diese Zweigstruktur als hierarchisch erkannt und angezeigt, wodurch der Verlauf eines Projekts auf oberster Ebene anhand der Zweigstruktur besser verständlich wird.

Entschuldigung, dass ich keine Antworten hochgestuft habe; Mein Ruf bei SO ist noch nicht das erforderliche Minimum.