Warum ist das Zusammenführen von Feature-Zweigen in Release-Zweigen eine schlechte Idee?

Question

Wir haben das von Vincent Driessen vorgeschlagene Verzweigungsmodell übernommen und machen fast alles so, wie er es in seiner article beschrieben hat.

Nur wenn es um den Umgang mit den Freigabezweigen geht, weichen wir etwas ab.

Vincent schlägt vor, Merkmale in Zweigen zu entwickeln, die vom Entwickler abgezweigt werden. Wenn entschieden wird, welche Features in das nächste Release kommen, werden sie zurück in den Entwickler zusammengeführt und daraus ein Release-Zweig erstellt.

Danach sollte der Feature-Zweig nur zum Testen und Bugfixing verwendet werden. Wenn das Release zum Leben bereitgestellt wird, wird der Release-Zweig wieder in Entwickler und Master zusammengeführt.

Was wir tun, ist stattdessen Funktionen direkt in den Release-Zweig zu fusionieren:

Ich glaube, dass dies nicht der Weg ist, es getan werden soll, und ich versuche die Fälle zu denken, wo dies tatsächlich machen könnte Dinge komplizierter.

One ich denken kann, ist die folgende:

ist eine neue Eigenschaft c sagen Lassen Sie baut auf Eigenschaft ein, die bereits in einen Release-Zweig verschmolzen. Ich muss zuerst den Release-Zweig zurück in den Entwickler zusammenführen, um einen neuen Zweig vom Entwickler erstellen zu können.

Gibt es andere Fälle, in denen dieses Verzweigungsmodell die Dinge komplizierter machen könnte?

Answer 1

Ein Fall, an den ich denken könnte, wo dies die Sache kompliziert machen kann ist, dass es beginnt, die weitere Entwicklung zu blockieren.

Bedenken Sie, dass Sie ein Feature A entwickeln, das sofort in Ihrem nächsten Release verfügbar sein wird. Jetzt gibt es ein anderes Entwicklungsteam, das an Feature B arbeiten wird, das stark von Feature A abhängig ist, aber erst nach ein paar Sprints veröffentlicht werden muss. Also, natürlich werden wir Feature B von Feature A verzweigen.

Nun, Sie finden einen Fehler in Feature A, Ihre Veröffentlichung für Feature A nähert sich schnell, haben Sie zwei Optionen eine Hot-Fix/Hack oder eine ordnungsgemäße Code neu einteilen und korrigieren.

Mit der Zeit als Einschränkung, ist es klug, Hot-Fix zu haben, aber in Anbetracht der Zukunft brauchen wir richtige Re-Faktor und zu beheben.

Eine gute Nachricht ist, dass wir für beide gehen können.

Mit Ihrer Strategie (von dem, was ich verstehe) Ihr Release-Zweig, erhalten alle Patches und Hot-Fixes (enthält 5+ Commits), wie Sie nichts dergleichen zu Feature A (wenn Sie streng sind Richtlinien). Betrachten Sie die Anzahl solcher Fixes, die Release haben wird, wenn Sie mehr als 10 Funktionen gleichzeitig haben.

Aber mit Vincent Driessen Strategie gibt es immer Entwicklungszweig als Stash zwischen Ihrem Feature und Release, also für solche Hotfixes können Sie zurück zum Entwicklungszweig verschmelzen und dann von dort für die Hotfixes verzweigen und dann wieder zusammenführen Entwicklung und dann zu veröffentlichen. Und Sie haben den Vorteil, dass Sie die Hacks/Hotfixes nirgends in Ihrem Feature-Zweig haben. Weitere Funktionen basierend auf der Funktion können parallel fortgesetzt werden. Und Sie können die Hotfix-Zweige verlassen oder aus dem Verlauf entfernen. Dieser einzige Standpunkt und wahrscheinlich können Sie in diesem Fall Ihre Strategie verteidigen. Ich bin offen für weitere Diskussionen und Korrekturen in meiner Antwort :)

Und hier ist ein ziemlich fieses Bild, das darstellt, was ich vermittele.