Git-Branch-Strategie für kleines Entwicklerteam [geschlossen]

Wir haben eine Web-App, die wir fast täglich aktualisieren und veröffentlichen. Wir verwenden git als unser VCS, und unsere derzeitige Verzweigungsstrategie ist sehr einfach und kaputt: Wir haben eine Hauptverzweigung und überprüfen Änderungen, bei denen wir uns gut fühlen. Dies funktioniert, aber nur bis wir eine Änderung einchecken.

Hat jemand eine bevorzugte Strategie für Git-Filialen für kleine Teams, die die folgenden Anforderungen erfüllt:

1. Funktioniert gut für Teams von 2 bis 3 Entwicklern
2. Leicht und nicht zu viel Prozess
3. Ermöglicht Entwicklern das einfache Isolieren der Arbeit an Fehlerkorrekturen und größeren Funktionen
4. Ermöglicht es uns, einen stabilen Zweig zu behalten (für jene "Oh Mist" -Momente, in denen wir unsere Produktionsserver zum Laufen bringen müssen)

Im Idealfall würde ich gerne Ihren schrittweisen Prozess für einen Entwickler sehen, der an einem neuen Fehler arbeitet

Sie könnten von dem Workflow profitieren, den Scott Chacon in Pro Git beschreibt . In diesem Workflow gibt es zwei Zweige, die immer existieren: Master und Entwicklung .

master stellt die stabilste Version Ihres Projekts dar und Sie stellen immer nur von diesem Zweig aus für die Produktion bereit.

Die Entwicklung enthält Änderungen, die gerade ausgeführt werden und möglicherweise nicht unbedingt produktionsbereit sind.

In der Entwicklungsniederlassung erstellen Sie Themenzweige, um an einzelnen Funktionen und Korrekturen zu arbeiten. Sobald Ihr Feature / Fix einsatzbereit ist, führen Sie es in die Entwicklung ein . An diesem Punkt können Sie testen, wie es mit anderen Themenbereichen interagiert, in denen Ihre Mitarbeiter zusammengeführt wurden. Sobald sich die Entwicklung in einem stabilen Zustand befindet, führen Sie es in den Master ein . Die Bereitstellung in der Produktion vom Master aus sollte immer sicher sein .

Scott beschreibt diese langjährigen Zweige als "Silos" von Code, in denen Code in einem weniger stabilen Zweig nach dem Testen und der allgemeinen Genehmigung durch Ihr Team schließlich zu einem "stabileren" Zweig "graduiert" wird.

Schritt für Schritt könnte Ihr Workflow unter diesem Modell folgendermaßen aussehen:

1. Sie müssen einen Fehler beheben.
2. Erstellen Sie einen Zweig namens myfix , der auf dem Entwicklungszweig basiert .
3. Arbeiten Sie an dem Fehler in diesem Themenzweig, bis er behoben ist.
4. Merge MyFix in der Entwicklung . Führen Sie Tests durch.
5. Sie entdecken Ihre Fixkonflikte mit einem anderen Themenzweig hisfix , den Ihr Mitarbeiter während der Arbeit an Ihrem Fix zur Entwicklung zusammengeführt hat .
6. Nehmen Sie weitere Änderungen im Zweig myfix vor , um diese Konflikte zu beheben .
7. Merge MyFix in der Entwicklung wieder Tests und laufen.
8. Alles funktioniert gut. Merge entwickeln in Master .
9. Stellen Sie die Produktion jederzeit vom Master aus bereit , da Sie wissen, dass sie stabil ist.

Weitere Informationen zu diesem Workflow finden Sie im Kapitel Verzweigungsworkflows in Pro Git.

Nachdem er als Anfänger reingekommen war und versucht hatte, eine einfache Strategie zu finden, um anderen Entwicklern beizubringen, die noch nie die Quellcodeverwaltung verwendet haben. Dies ist derjenige, der zu http://nvie.com/posts/a-successful-git-branching-model/ passt. Ich habe versucht, den Standard-GIT-Workflow zu verwenden, der in den Manpages enthalten ist, aber er hat mich und mein Publikum völlig verwirrt.

In den letzten 6 Monaten musste ich Konflikte nur zweimal beheben. Ich habe Schritte hinzugefügt, um immer nach einer Zusammenführung zu testen und viel (einmal am Morgen und am Nachmittag) zu "holen und zusammenzuführen" oder "zu ziehen", während ich Funktionen entwickle. Wir haben auch github.com als zentralen Ort verwendet, um den neuesten Code abzurufen.

(Mein Kommentar über seiner eigenen Antwort wurde gemacht, wie ich es ursprünglich hätte tun sollen.)

Von Scott Chacon aus Github:

Wie machen wir das? Was ist GitHub Flow?

• Alles in der Hauptniederlassung kann bereitgestellt werden
• Um an etwas Neuem zu arbeiten, erstellen Sie einen beschreibend benannten Zweig des Masters (dh: new-oauth2-scopes).
• Übertragen Sie sich lokal auf diesen Zweig und übertragen Sie Ihre Arbeit regelmäßig auf den gleichnamigen Zweig auf dem Server
• Wenn Sie Feedback oder Hilfe benötigen oder der Zweig zum Zusammenführen bereit ist, öffnen Sie eine Pull-Anfrage
• Nachdem eine andere Person die Funktion überprüft und abgemeldet hat, können Sie sie in master zusammenführen
• Sobald es zusammengeführt und an 'master' gesendet wurde, können und sollten Sie es sofort bereitstellen

Weitere Informationen finden Sie im gesamten Artikel: http://scottchacon.com/2011/08/31/github-flow.html

Beachten Sie, dass "Pull-Anfragen" eine Erfindung von Github sind und in ihre Website eingebrannt sind, nicht in Git selbst: https://help.github.com/articles/using-pull-requests/

Verwenden Sie den masterZweig als Entwicklungszweig und erstellen Sie Release-Zweige, um Fehlerbehebungen durchzuführen.

Alle neuen Funktionen werden masterwährend des Entwicklungsfensters fortgesetzt (entweder direkt festgeschrieben oder als Themenzweige mit Pull-Anforderungen an Sie - nicht in der Grafik dargestellt). Sobald alle geplanten Funktionen implementiert sind, geben Sie Feature Freeze ein und führen Sie Tests durch. Wenn Sie zufrieden sind, markieren Sie die Veröffentlichung masterals v1.0.

Im Laufe der Zeit werden Ihre Benutzer Fehler finden, v1.0daher sollten Sie aus diesem Tag einen Zweig erstellen (z. B. nach der Veröffentlichung benennen 1.0) und diese Fehler im Zweig beheben. Wenn Sie genug Fehler behoben haben, von denen Sie glauben, dass sie eine neue Version rechtfertigen, markieren Sie sie als v1.0.1und führen Sie sie wieder zusammen master.

In der Zwischenzeit kann ein neues Entwicklungsfenster für den masterZweig entstehen, das schließlich als gekennzeichnet wird v1.1.

Spülen & wiederholen.

Dies folgt der Nummerierungslogik der semantischen Versionierung .

 ---------(v1.0)--------------------------------(v1.1)-----------------------------> master
             \                                     \  
              ---(v1.0.1)---(v1.0.2)---> 1.0        ---(v1.1.1)---(v1.1.2)---> 1.1

In einem VCS zeigt ein "Master" -Zweig schnell seine Grenzen, da Sie nicht den gesamten Entwicklungsaufwand gleichzeitig für einen Zweig ausführen können.
Das heißt, Sie müssen wissen, wann Sie verzweigen müssen .

In einem DVCS (wie in "Dezentralisiertem" VCS) gibt es jedoch auch ein Veröffentlichungsproblem mit Zweigen, die Sie lokal in Ihren Repositorys aufbewahren, und Zweigen, in die Sie pushen oder aus denen Sie ziehen.

Identifizieren Sie in diesem Zusammenhang zunächst Ihren gleichzeitigen Entwicklungsaufwand und entscheiden Sie sich für einen Veröffentlichungsprozess (Push / Pull). Zum Beispiel (und dies ist nicht der einzige Weg):

• prod ist eine schreibgeschützte öffentliche Niederlassung mit dem Code in der Produktion. Jeder konnte daraus ziehen, um:
  • Darüber hinaus wird die aktuelle Entwicklung neu gestartet (zum lokalen Testen oder zum Integrieren eines Hotfixes, der im Prod Repo im Prod-Zweig ausgeführt wird, in das lokale Entwickler-Repo).
  • Verzweigen, um neue Funktionen auszuführen (aus einem bekannten stabilen Code)
  • Verzweigen, um den nächsten Release-Zweig zu starten (den, der in Produktion sein soll).
    Niemand sollte direkt auf Prod drücken (daher der schreibgeschützte Zweig ).
• Release ist ein Lese- / Schreib-Konsolidierungszweig, in dem die relevanten Commits ausgewählt werden, um Teil der nächsten Version zu sein.
  Jeder kann auf die Veröffentlichung drängen, um die nächste Version zu aktualisieren.
  Jeder kann von dieser Version abrufen, um seinen lokalen Konsolidierungsprozess zu aktualisieren.
• featureX ist ein privater Lese- / Schreibzweig (da er nicht auf das zentrale Produkt-Repo übertragen werden muss) und kann zwischen Entwicklungs-Repos verschoben / gezogen werden. Es stellt eine mittel- bis langfristige Anstrengung dar, die sich vom täglichen Entwickler unterscheidet
• Der Master repräsentiert den aktuellen Entwickler und wird zwischen den Entwickler-Repos verschoben / gezogen.

Es gibt andere Release-Management-Prozesse, wie diese SO-Frage bestätigt .

Lesen Sie hier den Git Workflow für agile Teams von ReinH: http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html

Dies funktioniert sehr gut für kleine Teams. Ziel ist es, sicherzustellen, dass alles, was möglicherweise instabil ist, in eine Zweigstelle gelangt. Führen Sie die Verbindung erst dann zum Master zurück, wenn Sie bereit sind, dass alle Mitarbeiter außerhalb des Feature-Zweigs sie verwenden.

Hinweis: Diese Strategie ist kaum git-spezifisch, aber git macht die Implementierung dieser Strategie ziemlich einfach.