Verschiedene Ansätze zur Verzweigung der Quellcodeverwaltung

Question

Wenn ich die Quellcodeverwaltung verwende, bin ich es gewohnt, auf dem Stamm zu arbeiten und dann den Stamm abzuzweigen, kurz bevor ich in QA übergehe.

Ich habe mit einigen anderen Leuten in der Abteilung gesprochen und anscheinend gibt es einige leidenschaftliche Ansichten über eine andere Art zu arbeiten, die den neuen Zweig am Anfang des Entwicklungszyklus kreieren würde verzweigen und dann am Ende zum Stamm zurückführen. Die Idee zu diesem Ansatz ist, den Stamm makellos zu halten. Die Skepsis gegenüber der Behauptung, dass ein Befürworter den letzteren Ansatz als den "Standard" -Ansatz bezeichnet hat (obwohl er froh darüber wäre, etwas anderes zu erfahren), würde mich nicht wundern, wenn ich höre, dass dies ziemlich häufig vorkommt. Ich kann mir einige Vorteile vorstellen (einfacher zu wählen und zu entscheiden, wann welche Funktion oder Gruppe von Funktionen implementiert werden soll), aber auch einige Nachteile (mögliche Zusammenführungsprobleme, da jeder einzelne Zweig wieder mit der Verbindungsleitung verbunden werden muss).

habe einige weitere Forschung und fanden diese: http://www.lostechies.com/blogs/derickbailey/archive/2009/07/15/branch-per-feature-source-control-introduction.aspx

Würde gespannt sein von Menschen, für die relativen Stärken und Schwächen dieser Ansätze sind, und auch über andere Ansätze ihren Sinn zu hören, dass die Menschen möglicherweise verwenden.

Answer 1

Dies ist eine sehr ähnliche Frage zu diesem früheren Artikel SO:

Subversion - should anyone be developing off the trunk?

nicht genau identisch, aber viele der Konzepte in den Antworten sind die gleichen.

Meine persönliche Meinung? Der Stamm ist für aktive Entwicklung; Entwicklungslinien älterer Versionen, die "makellos" bleiben sollen, sollten in Versionszweigen (und Tags für Releases) enthalten sein. Sie können immer noch versuchen, eine "der Stamm sollte immer kompilieren" Maxime beizubehalten, auch wenn die aktive Entwicklung auf dem Stamm ist.

Answer 2

Mit einem Team, das an den gleichen Sachen arbeitet, ist es ein ziemlich netter Ansatz, im Kofferraum zu arbeiten und vor der Veröffentlichung einen Zweig zu erstellen. Du minimalisierst Merge-Hell, und du hast für jede Veröffentlichung einen eigenen Zweig, wenn du einen Patch machen musst oder aus irgendeinem Grund zurückgehen musst.

Aber wenn man mit mehreren Teams arbeitet, die getrennte Dinge tun, wird das nicht funktionieren, da sie höchstwahrscheinlich im Kofferraum kollidieren werden. Ich habe nicht viel Erfahrung damit, also freue ich mich auf einige Ideen dazu. Ein Ansatz wäre es, mehrere Zweige zu haben, einen für jedes Team, und dann die Zweige, die im Stamm in die Freigabe gehen. (Ich kann mir nur die Frustration vorstellen) :)

Answer 3

Ich bevorzuge den Kofferraum sauber zu halten. Dies ermöglicht es, jederzeit eine funktionierende Version zu kompilieren, einen Fix, eine Beta zu veröffentlichen, eine Demoversion zu erstellen ...

Änderungen werden an getrennten Zweigen vorgenommen. Dies ergibt eine bessere Rückverfolgbarkeit, und man kann die Quellcodeverwaltung in der Verzweigung nutzen und Zwischenversionen einchecken. In einer idealen Welt werden Zusammenführungsprobleme durch [automatische] Tests abgedeckt. Je früher Sie die Änderungen in den Stamm integrieren, desto besser.

Legen Sie keinen ungeprüften Code auf den Stamm, da dies letztendlich jemanden verlangsamen wird.