wake-up-neo.com

Git Branch Strategie für kleines Entwicklerteam

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 fehlerhaft: Wir haben eine Master-Verzweigung und überprüfen Änderungen, bei denen wir uns "wohl fühlen". Dies funktioniert jedoch nur, bis wir eine Änderung eingecheckt haben.

Hat jemand eine Lieblingsgit-Zweigstrategie 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, die Arbeit an Fehlerkorrekturen und größeren Funktionen mühelos zu isolieren
  4. Ermöglicht es uns, einen stabilen Zweig aufrechtzuerhalten (für die 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

182
Bilal and Olga

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

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

develop enthält Änderungen, die gerade durchgeführt werden und möglicherweise nicht für die Produktion bereit sind.

Aus dem Zweig entwickeln erstellen Sie Zweigzweige, um an einzelnen Funktionen und Korrekturen zu arbeiten. Sobald Ihr Feature/Fix einsatzbereit ist, fügen Sie es in develop ein. An diesem Punkt können Sie testen, wie es mit anderen Zweigzweigen Ihrer Kollegen interagiert zusammengeführt haben. Sobald entwickeln in einem stabilen Zustand ist, führen Sie es in Master . Es sollte immer sicher sein, das Deployment vom Master in die Produktion durchzuführen.

Scott beschreibt diese langjährigen Zweige als "Silos" des Codes, in denen Code in einem weniger stabilen Zweig nach dem Testen und der allgemeinen Genehmigung durch Ihr Team 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 mit dem Namen myfix , der auf dem Entwicklungszweig basiert.
  3. Bearbeiten Sie den Fehler in diesem Zweig, bis er behoben ist.
  4. Füge myfix in develop ein. Führen Sie Tests durch.
  5. Sie entdecken, dass Ihr Fix Konflikte mit einem anderen Themenzweig hat, dessen Fix Ihr Kollege entwickelt während du an deinem Fix gearbeitet hast.
  6. Nehmen Sie weitere Änderungen im Zweig myfix vor, um diese Konflikte zu lösen.
  7. Füge myfix in Develop ein und führe die Tests erneut aus.
  8. Alles funktioniert gut. Zusammenführen Entwickeln zu Master .
  9. Sie können jederzeit vom Master in der Produktion bereitstellen, da Sie wissen, dass es stabil ist.

Weitere Informationen zu diesem Arbeitsablauf finden Sie im Kapitel Verzweigungsarbeitsabläufe in Pro Git.

238
Jimmy Cuadra

Nachdem ich als Neuling reingekommen bin und versucht habe, eine einfache Strategie zu finden, um anderen Entwicklern beizubringen, die noch nie die Quellcodeverwaltung verwendet haben. Dies ist derjenige, der passt http://nvie.com/posts/a-successful-git-branching-model/ Ich habe versucht, den Standard-GIT-Workflow zu verwenden, der in den Manpages enthalten ist, aber das hat mich ein wenig verwirrt und mein Publikum komplett.

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 eine Menge (morgens und nachmittags) abzurufen und zusammenzuführen oder abzurufen, während Features entwickelt werden. Wir haben auch github.com als zentralen Ort zum Abrufen des neuesten Codes verwendet.

45
Clutch

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

Von Scott Chacon von Github:

Wie wir es machen Also, was ist GitHub Flow?

  • Alles im Master-Zweig kann implementiert werden
  • Um an etwas Neuem zu arbeiten, erstellen Sie eine beschreibend benannte Verzweigung von master (dh new-oauth2-scopes).
  • Lokale und regelmäßige Übergabe an diesen Zweig Schieben Sie Ihre Arbeit an den Zweig mit dem gleichen Namen auf dem Server
  • Wenn Sie Feedback oder Hilfe benötigen oder glauben, dass der Zweig zum Zusammenführen bereit ist, öffnen Sie eine Pull-Anforderung .
  • Nachdem eine andere Person das Feature überprüft und abgemeldet hat, können Sie es in master zusammenführen
  • Sobald es zusammengeführt und auf "master" verschoben 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-Requests" eine Erfindung von Github sind und auf deren Website eingebrannt wurden, nicht auf Git selbst: https://help.github.com/articles/using-pull-requests/

35
program247365

Verwenden Sie den Zweig master als Entwicklungszweig und erstellen Sie Versionszweige, um Fehler zu beheben.

Alle neuen Funktionen werden während des Entwicklungsfensters auf master gesetzt (entweder direkt oder als Zweig mit Pull-Requests - in der Grafik nicht dargestellt). Sobald alle von Ihnen geplanten Funktionen implementiert sind, geben Sie Feature Freeze ein und führen Sie Tests durch. Wenn Sie zufrieden sind, markieren Sie die Veröffentlichung auf master als v1.0.

Im Laufe der Zeit werden Ihre Benutzer Fehler in v1.0 Finden. Daher möchten Sie aus diesem Tag einen Zweig erstellen (z. B. nach der Veröffentlichung 1.0 Benennen) und diese Fehler in dem Zweig beheben. Wenn Sie genügend Fehler behoben haben, die Ihrer Meinung nach eine neue Version rechtfertigen, markieren Sie sie als v1.0.1 Und führen Sie sie wieder zu master zusammen.

In der Zwischenzeit kann auf dem Zweig master ein neues Entwicklungsfenster auftreten, das schließlich mit v1.1 Markiert wird.

Spülen und wiederholen.

Dies folgt Semantic Versioning Nummerierungslogik.

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

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

Aber in einem DVCS (wie in "Dezentralisiertem" VCS) haben Sie auch ein Publikationsproblem mit Zweigen, die Sie lokal halten zu Ihren Repositories und Zweigen, zu denen Sie pushen oder von denen Sie pushen.

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

  • prod ist eine öffentliche schreibgeschützte Zweigstelle mit dem Code in der Produktion. Jeder konnte daran ziehen, um:
    • die aktuelle Entwicklung darauf aufbauen (für lokale Tests oder für die Integration eines Hotfixes auf dem lokalen Dev Repo, der im Prod Repo auf dem Prod Branch durchgeführt wurde)
    • verzweigen, um neue Funktionen auszuführen (von einem bekannten stabilen Code)
    • branch, um den nächsten Release-Zweig zu starten (derjenige, der in Produktion sein soll)
      Niemand sollte direkt auf stoßen (daher das schreibgeschützte)
  • release ist ein Lese-Schreib-Konsolidierungszweig, in dem die relevanten Commits ausgewählt werden, um Teil des nächsten Releases zu sein.
    Jeder kann Push-to-Release ausführen, um das nächste Release zu aktualisieren.
    Jeder kann von dieser Veröffentlichung Gebrauch machen, um seinen lokalen Konsolidierungsprozess zu aktualisieren.
  • featureX ist ein privater Lese-/Schreibzweig (dh, er muss nicht an das zentrale Produktrepository gesendet werden) und kann zwischen Entwicklungsrepos verschoben/verschoben werden. Es ist eine mittel- bis langfristige Anstrengung, die sich von der täglichen Entwicklung unterscheidet
  • master repräsentiert den aktuellen dev und wird zwischen den dev repos verschoben/gezogen.

Andere Release-Management-Prozesse existieren, wie dies SO-Frage bestätigt .

4
VonC

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. Das Ziel hierbei ist es, sicherzustellen, dass alles, was möglicherweise instabil ist, in eine Art Zweig gelangt. Führen Sie die Zusammenführung nur dann zum Master zurück, wenn Sie bereit sind, dass alle Benutzer außerhalb des Feature-Zweigs sie verwenden können.

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

3
whaley