Ein perfektes Branching Modell für die Softwareentwicklung

Versionskontrolle ist ein essentielles Tool der Softwareentwicklung. Ich betreibe meine Entwicklung im Trunk, wenn die Revision produktreif ist, wird ein Tag angelegt und dieser ausgeliefert. Soweit so gut, dann tauchen Probleme auf und ein Hotfix wird notwendig. Da die Entwicklung aber fortgeschritten ist,  wird der Fix im Tag erledigt. Dann zurück in den Trunk gemerged. Das ist zwar praktikabel doch wirklich schön ist das vorgehen nicht.

Vor einigen Wochen habe ich auf dem Blog von Vincent Driessen einen Artikel über ein Git Branching Modell gelesen.

Next to the main branches master and develop, our development model uses a variety of supporting branches to aid parallel development between team members, ease tracking of features, prepare for production releases and to assist in quickly fixing live production problems. Unlike the main branches, these branches always have a limited life time, since they will be removed eventually.

The different types of branches we may use are:

• Feature branches
• Release branches
• Hotfix branches

Each of these branches have a specific purpose and are bound to strict rules as to which branches may be their originating branch and which branches must be their merge targets. We will walk through them in a minute.

Die Grafik verdeutlicht das Vorgehen.

Nachdem ich dieses Vorgehen verinnerlicht und für ein kleines Projekt angewandt habe, erlaube ich mir das Fazit: es funktioniert :). Ich würde dieses Modell als nächstes in einem Projekt einsetzen, in dem Subversion zum Einsatz kommt. Weitere Schwierigkeiten sehe ich da vielleicht mit Hudson-CI und Maven. Ich werde berichten.