tag Beratung zu mehreren Freisetzungslinien und Git-Flow für Git-Nicht-Gurus




git tagging best practices (3)

Eine Lösung besteht darin, die Konfigurationsvariable gitflow.branch.develop zu ändern. Sie erstellen eine Branche in Ihrer freigegebenen Version und verwenden diese als Ihre neue Entwicklungsbranche. Von dort verwenden Sie die üblichen git-flow-Befehle. Wenn Sie diese Arbeit automatisch wieder in den ursprünglichen Entwicklungszweig zusammenführen gitflow.branch.develop , ändern Sie die Variable gitflow.branch.develop vor dem Befehl git-flow finish.

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 das Verzweigungsmodell von Driessen zu nutzen . Wir haben ein sehr kleines Softwareteam mit wenigen engagierten Entwicklern (wir tragen alle viele Hüte) und keinen "Integrationsguru".

Viele Suchanfragen haben wenig konkrete Hinweise ergeben, wie Git und Git Flow an unsere Bedürfnisse angepasst werden können. Es hat sich gezeigt, dass Git Flow nicht für die gleichzeitige Unterstützung mehrerer Versionen geeignet ist. In einer verwandten Diskussion über SO gibt es Antworten, die darauf hinweisen, dass separate Zweignamen verwendet werden müssen, um die Historien der separaten Versionen zu verfolgen. Durch diese und verwandte Strategien wird Git Flow eliminiert, sofern es nicht geändert wird. Siehe unsere Teambeschränkungen für einen Grund, warum dies für uns nicht praktikabel ist.

Die Schlüsselfrage lautet: Was haben andere für einen guten Ansatz gefunden, um das Verzweigungsmodell von Driessen so nah wie möglich zu implementieren und gleichzeitig mehrere Release-Linien zu unterstützen?

AKTUALISIERUNG:

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

Wir werden Git Flow nicht weiter verwenden. Stattdessen wenden wir das Modell von Driessen auf jede einzelne Releasezeile in einem Repo an, indem Sie jedem Zweignamen die gewünschte Releasezeichenfolge voranstellen, z. B .:

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 der Release-String vorangestellt ist (z. B. r1.6/develop und in unserem Fall r1.6/release , kein master mit seiner Implikation des Einzelstroms guter bebaubarer Zustand).

Wir richten pro Projekt ein zentrales öffentliches Repository auf einem Server ein, der der Hauptweg für die gemeinsame Nutzung von Code über lokale Repo- remote Links ist. Ein Push auf dieses Repository zeigt Code an, der von anderen genutzt werden kann. Das Zusammenführen von RX.Y/develop in den Zweig RX.Y/release und anschließendes Drücken von RX.Y/release bedeutet Code, der für die Veröffentlichung vorgesehen ist. feature , hotfix , et. al. Filialen werden ähnlich behandelt. Die Verzweigungs- / Festschreibungshistorie für eine gegebene Versionszeile ist sauber und verständlich. Wir wollen nicht die typische Git-Strategie für verteilte Repos, um die Komplexität des Zusammenführens solcher Repos zu vermeiden, die im Laufe der Zeit wahrscheinlich in ihrer Struktur abweichen.

In einigen Git-GUIs (wie zum Beispiel SourceTree) wird diese Zweigstruktur als hierarchisch erkannt und angezeigt. Dies hilft, den Verlauf der obersten Ebene eines Projekts anhand der Zweigstruktur zu verstehen.

Entschuldigung, dass ich keine Antworten gewählt habe; Mein Ruf bei SO ist noch nicht das Minimum, das dazu nötig ist.


Unser gewöhnlicher Entwicklungsprozess passt gut zum Flussworkflow von Driessen, aber manchmal müssen wir eine Zweigstelle mit mehreren Funktionen für eine spezielle Version entwickeln, in der wir den Großteil der laufenden Entwicklung nicht wünschen. Wir haben mit den vorhandenen Tools einen Weg gefunden, dies mit wenigen zusätzlichen Schritten innerhalb von flow zu erreichen. (Wir arbeiten in mercurial, aber die Optionen für git flow und hg flow sind die gleichen.)

Zum Beispiel ist unsere nächste normale Version 23.0 und unsere spezielle "Sandkasten" -Version 22.4.2. Für diese Fälle:

  1. Erstellen Sie frühzeitig, bevor die neuen Funktionen erstellt werden, einen Release-Zweig 22.4.2 für die Sonderfreigabe von Develop. Es ist in Ordnung, wenn einige Funktionen früher gestartet wurden, solange sie nicht nach einer Arbeit ausgeführt werden, die wir ausschließen möchten.
  2. Machen Sie dort ein Tag zur Vereinfachung (start-22.4.2)
  3. Starten Sie jedes neue 22.4.2-Feature mit start-22.4.2 (ein Changeset beim Entwickeln) als übergeordnetes Element / Basis . Dadurch wird verhindert, dass in der Zwischenzeit zusammengeführte Arbeiten auf den Freigabezweig gelangen. Sowohl die Befehlszeile als auch Sourcetree unterstützen die Auswahl eines übergeordneten Elements neben dem Tipp für den git flow feature start .
  4. Mischen Sie manuell von der Spitze des Zweigs 22.4.2 zum Feature, falls gewünscht, und so oft wie gewünscht, um alle fertiggestellten Features aus dem Zweig zu übernehmen. Auf diese Weise können wir uns mit allen Interaktionen mit Besorgnis zwischen den neuen 22.4.2-Funktionen der Branche beschäftigen.
  5. git flow feature finish das Feature, das es zusammenführt, um wie gewohnt zu entwickeln. (Für uns sind diese Funktionen in zukünftigen Versionen enthalten. Wir schützen nur 22.4.2 vor weniger getesteten Arbeiten.)
  6. Nach dem Fertigstellen fügen wir die letzte Änderungsmenge vor dem Schließen des Features manuell in den Zweig 22.4.2 ein.

Wir haben ein ähnliches Setup mit der Ausnahme, dass wir mehr als 300 dedizierte Entwickler haben. Wir haben genau das, was Sie beschrieben haben, mehrere Revisionen, die wir an verschiedene Kunden liefern müssen.

Wir haben es geteilt, so dass wir einen ersten Ref wie Refs / Heads / PlatformX.Y / haben. Dann bauen wir darauf auf

Abhängig davon, was Sie tun müssen, checken Sie platformX.Y / Entwicklung und beginnen an diesem Punkt an einem Funktionszweig zu arbeiten, und Sie werden wieder zusammengeführt, um sich zu entwickeln, wenn Sie fertig sind.

Dies funktioniert für uns und wir können dem neuen Modell folgen.

Darüber hinaus führen wir alle diese platformX.Y-Niederlassungen zu unserem Hauptentwicklungszweig zusammen, so dass in diesen Niederlassungen korrigierte Fehler auch in der neuesten Software veröffentlicht werden.





git-flow