it-swarm.com.de

Verwenden von Gitflow und semantischer Versionierung: Wie vermeide ich Versionsnummernkonflikte beim Zusammenführen?

Ich möchte gitflow in Kombination mit semantischer Versionierung verwenden. In gitflow stoßen Sie Versionsnummern für jede Version oder jeden Hotfix-Zweig an. Dies führt unweigerlich zu Versionskonflikten, wenn ein neuer Entwicklungszyklus (mit einer neuen Versionsnummer) gestartet wird, während der aktuelle Release-Prozess noch läuft.

Nehmen wir an, 1.0.0 ist auf Master und bei der Entwicklung starte ich die neue Version 2.0.0. Jetzt tritt ein Hotfix vom Master auf (1.0.1). Beim Zusammenführen des Hotfixes mit dem Entwicklungszweig tritt ein Konflikt auf.

Es gibt eine etwas ähnliche Frage hier auf SE @ Stackexchange, mit einem großen Unterschied: Da meine Gradle- und Maven-Build-Tools stark von Versionsnummern abhängen, muss ich sie in meinem Code speichern und kann nicht einfach Generieren Sie sie beim Erstellen einer Version. Und ich muss die Versionsnummer bei der Entwicklung für einen neuen Veröffentlichungszyklus erhöhen, sonst werden Artefakte überschrieben.

Wie kann ich meine Zweige und Versionsnummern so verwalten, dass keine Zusammenführungskonflikte auftreten können?

9
Franz Wimmer

Sie können diesen Zusammenführungskonflikt nicht vernünftigerweise vermeiden. Es handelt sich jedoch um einen sehr geringfügigen Konflikt, der während des Zusammenführens leicht zu lösen ist. Stellen Sie jedoch sicher, dass die Versionsnummer nur in der Quelldatei one geschrieben ist.

Hotfixes sind wahrscheinlich selten genug, dass eine manuelle Auflösung ausreicht. Es kann jedoch sinnvoll sein, eine Art Test hinzuzufügen, bei dem die korrekte Versionsnummer beibehalten wurde, z. Ein Skript, mit dem überprüft wird, ob die Versionsnummer in einem Commit von allen übergeordneten Commits monoton ansteigt. Das Zusammenführen der Versionen 1.0.1 und 2.0.0 würde zu> = 2.0.0 führen.

Beachten Sie, dass der Git-Flow nicht immer ein anwendbares Verzweigungsmodell ist. Es richtet sich an Szenarien mit klaren, etwas seltenen Releases, in denen Sie möglicherweise alte Releases unterstützen müssen. Dies kann gut für Standardanwendungen oder Bibliotheken geeignet sein.

Git-Flow passt nicht, wenn Sie alle Bereitstellungen/Benutzer auf die neueste Version aktualisieren können, z. für Inhouse-Software, SaaS oder Web/Mobile-Apps. Dann könnte ein anderes Verzweigungsmodell ohne Release-Verzweigungen besser geeignet sein. Dies bedeutet, dass sich Ihr Entwicklungszweig immer in einem freigebbaren Zustand befindet, was wiederum bedeutet, dass alle zusammengeführten Features zur Veröffentlichung bereit sind OR sind durch einen Feature-Toggle geschützt. Ein Hotfix ist dann ein gewöhnlicher Funktion für die nächste Version, und es ist kein Backporting/Zusammenführen des Hotfix erforderlich.

7
amon