Wann in Git verzweigen?

Ich habe gerade angefangen, Git zu verwenden, und obwohl es relativ einfach ist, herauszufinden, wie man etwas mit Git macht, habe ich Probleme, es herauszufinden wann etwas mit git machen.

Wann verzweigt man zum Beispiel normalerweise ein Projekt?

Ich habe darüber nachgedacht, jede Version eines aktuellen Projekts zu verzweigen und wenn es fertig ist, es mit dem Master zusammenzuführen – ist das gängige Praxis?

Ich bin mir sicher, dass es Menschen gibt, die Dinge anders machen als ich. Allerdings halte ich mich an folgendes:

• Erstellen Sie immer einen Zweig für jedes Feature (führen Sie sie später wieder zusammen)
• Erstellen Sie einen Zweig für jede Fehlerbehebung
• Lassen Sie den Master-Branch sauber sein, indem Sie ihn nicht zu einem Work In Progress (WIP) machen

Ich bin mir nicht sicher, was Sie meinen, indem Sie jede Version des aktuellen Projekts verzweigen.

Wie auch immer, git empfiehlt, dass Sie einen „Themenzweig“ erstellen. „Themenzweig“ bedeutet, dass Sie einen Zweig erstellen, wenn Sie an einem Feature/Bug arbeiten. Nehmen wir an, ich arbeite an jQueryUI und wurde gebeten, eine Funktion zu jQuery Calendar hinzuzufügen, mit der Benutzer Daten angeben können, die nicht auswählbar sind.

Wenn ich mich im Branch namens master befinde, erstelle ich einen lokalen Branch namens „SpecifyDateExclusion“ Branch und beginne mit meinen Änderungen. Jeglicher Code, der sich auf diese Funktion bezieht, wird in diesen Zweig eingefügt.

master
  |
  |
  |___ SpecifyDateExclusion

Während ich an dieser Funktion arbeite, kommt ein Fehlerbericht, dass der Kalender in Opera 10 kaputt ist und dieser Fehler jetzt behoben werden muss. Ich gehe zurück zu meinem Master-Zweig und erstelle einen weiteren Zweig namens Opera10BugFix und beginne mit der Fehlerbehebung darin.

master
  |
  |
  |___ SpecifyDateExclusion
  |
  |
  |___ Opera10BugFix

Sehr bald können Sie Filialen wie haben

master
  |
  |
  |___ SpecifyDateExclusion
  |
  |___ Feature1
  |
  |___ Feature2
  |
  |___ Feature3
  |
  |___ Opera10BugFix
  |
  |___ BugFix1
  |
  |___ BugFix2

Was ist der Vorteil, den Sie fragen können?

Der Vorteil ist die Flexibilität, die es mir bei der Vorbereitung meiner Entlassung gibt. Nehmen wir an, in meiner nächsten Veröffentlichung geht es hauptsächlich um Fehlerbehebungen.

Ich werde einen neuen Branch mit dem Namen „InterimBugFix“ von master erstellen und alle meine Bugfix-Branches zusammenführen.

Wenn ich eine Mischung aus Bug-/Feature-Release erstellen möchte, erstelle ich einen Branch mit dem Namen „NextVersion“ vom Master und führe meine Feature-/Bugfixe-Zweige zusammen.

Git ist extrem mächtig darin, wie Sie diese Branches verwalten, und wenn Sie sich etwas vorstellen können, lässt Git es Sie tun.

Das Beste an Git ist, dass es Ihnen keine Entscheidungen aufzwingt. Das Schlimme an Git ist, dass es Ihnen keine Entscheidungen aufzwingt.

Ihr Arbeitsablauf liegt ganz bei Ihnen. Beabsichtigen Sie eine Zusammenarbeit oder entwickeln Sie sich unabhängig? Haben Sie eine kurze oder lange Vorlaufzeit zwischen den Veröffentlichungen? Diese Einschränkungen können helfen, einen geeigneten Arbeitsablauf zu definieren.

Ich arbeite in einem kleinen Team von 4 Entwicklern mit einem zweiwöchigen Iterationszyklus. Zu Beginn des Zyklus einigen wir uns auf einen Umfang und entwickeln uns gegen den Meister. Alles, von dem wir erwarten, dass es die zwei Wochen überschreitet, wird in einen Zweig verschoben (oder beginnt das Leben) (das kommt nicht oft vor, unser Spielraum ist eng).

Am Ende des zweiwöchigen Zyklus führen wir unsere Qualitätssicherung, Kennzeichnung und Freigabe durch. Beginnend mit dem nächsten Zyklus werden diese anderen Zweige wieder mit dem Master zusammengeführt.

Wenn Sie ein Release patchen müssen, erstellen wir einen Branch, Commit, QA, Tag und Release.

Für alles Experimentelle erstellen wir im Allgemeinen einen neuen Zweig und halten ihn vom Master isoliert, bis er zum Zusammenführen oder Verwerfen geeignet ist.

Zusammenfassend verzweigt sich unser Team, wenn:

• Funktionen überschreiten unseren Iterationszyklus
• Patchen Sie eine Version
• Erlebnismerkmale

Unser Workflow ist sehr zentralisiert und wahrscheinlich nicht typisch für viele Git-Benutzer. Weder ist richtig noch falsch, es geht nur darum, das Passende auszuwählen.

In der Entwicklung von Webanwendungen tun wir Folgendes:

Wir unterhalten einen reinen Zweig namens “Produktion”. Es enthält den Code, der auf den Live-Websites vorhanden ist.

Alle Änderungen daran werden in Aufgabenzweigen vorgenommen. Möglicherweise sehen Sie also einen Zweig Task-13923-add-feature-x. Diese Zweige sind aus dem Produktionszweig erstellt und der Produktionszweig müssen mit ihnen verschmolzen werden vor dem Zusammenführen in die Produktion (es ist also immer ein sauberer schneller Vorlauf, keine potenziellen Konflikte).

Alle anderen führen den Zweig „Produktion“ von Zeit zu Zeit in ihre Aufgabenzweige ein, um auf dem Laufenden zu bleiben.

Im Zweifelsfall abzweigen. Filialen sind billig, und Informationen von neuen Filialen können leicht auf alte Filialen übertragen werden. Wenn ein Zweig seine Nützlichkeit überschritten hat, kann er leicht getötet werden.

Darauf gibt es je nach “Verzweigungsstrategie” viele Antworten. Die 2 einfachsten (meiner Erfahrung nach) sind Task/Feature-Zweige und Release-Zweige. Welche Sie verwenden, hängt unter anderem davon ab, wie Ihr Release-Zyklus funktioniert.

Wenn Sie kontinuierlich integrieren und veröffentlichen, sind Aufgaben-/Funktionszweige sinnvoll, da sie den “Master” (Stamm in anderen VCS) in einem relativ stabilen Zustand verlassen, was die Veröffentlichung erleichtert. Aber wenn Sie einen strukturierteren Release-Zyklus haben, sind Release-Zweige vielleicht sinnvoller, da sie verwendet werden können, um genauer zu definieren, was zu jedem Release hinzugefügt wird. Natürlich ist auch eine Hybridstrategie denkbar.

Normalerweise verwende ich Aufgaben-/Feature-Zweige, also wird jeder Fehler oder jede Feature-Anfrage verzweigt. Dann wird weitergearbeitet und nach Fertigstellung wieder in den Master eingebunden.