Sinnvolle Branch-Strukturfür die Pflege eines Versionstands und die Entwicklung einer neuen Version

[Auge]

Hallo

Ich habe eine Frage an die Git-, HG- oder die Cracks anderer Versionssysteme.

In einem Projekt gibt es aktuell einen gewissen Versionsstand, der bisher im Master eines Git-Repositories gepflegt wird. Bis jetzt verläuft die Entwicklung ziemlich linear. Nun ist geplant, diesen Stand vorerst weiterhin zu pflegen, aber gleichzeitig eine neue Version zu entwickeln. Beispiel sei der Zweig 1.3.x, für den weiterhin Bugs behoben werden sollen und der Entwicklungszweig für die Version 1.4(.x), in die neue Funktionen einfließen sollen.

Wie bilde ich soetwas sinnvoll in einem Git-Repo ab? Für den 1.4-er Zweig einen eigenen Branch, quasi einen Submaster zu erzeugen und die neuen Features dorthin zu mergen, ist mir verständlich. Aber was mache ich mit den Fixes für den 1.3.er Zweig? Die kann ich ja schlecht in den Master einfließen lassen. Mit einiger Wahrscheinlichkeit platzt mir das spätestens dann mit Merge-Konflikten, wenn der Stand des 1.4-er Zweigs in den Master einfließen soll.

Ist es sinnvoll, auch den 1.3.er Zweig vom Master aus abzuzweigen und alle weiteren Änderungen nur noch in diesem Zweig vorzunehmen beziehungsweise dort hinein zu mergen? Tags für neue Versionen kann ich ja wohl genausogut in irgendeinem Zweig anlegen, oder? Ist so ein Vorgehen konsistent, insbesondere in Hinsicht auf zukünftige Entwicklungen (1.5, 1.6, …)?

Das ganze wird auf Github gepflegt werden. Gibt es in dieser Hinsicht noch weiteres zu beachten?

Tschö, Auge