Welche Git-Verzweigungsmodelle funktionieren für Sie?

Unser Unternehmen verwendet derzeit ein einfaches Trunk- / Release- / Hotfixes-Verzweigungsmodell und möchte Ratschläge dazu, welche Verzweigungsmodelle für Ihr Unternehmen oder Ihren Entwicklungsprozess am besten geeignet sind.

1. Workflows / Verzweigungsmodelle

   Im Folgenden sind die drei Hauptbeschreibungen aufgeführt, die ich gesehen habe, aber sie widersprechen sich teilweise oder gehen nicht weit genug, um die nachfolgenden Probleme zu lösen, auf die wir gestoßen sind (wie unten beschrieben). Daher verwendet unser Team bisher standardmäßig nicht so gute Lösungen. Machst du etwas besseres

   • gitworkflows (7) Handbuchseite
   • (nvie) Ein erfolgreiches Git-Verzweigungsmodell
   • (reinh) Ein Git-Workflow für agile Teams

2. Zusammenführen gegen erneutes Basieren (Wirren gegen sequentielle Geschichte)

   Sollte man pull --rebaseoder mit dem Zusammenführen zur Hauptlinie warten, bis Ihre Aufgabe beendet ist? Persönlich neige ich zur Verschmelzung, da dadurch eine visuelle Darstellung erhalten bleibt, auf welcher Basis eine Aufgabe gestartet und beendet wurde, und ich bevorzuge sogar merge --no-ffdiesen Zweck. Es hat jedoch andere Nachteile. Viele haben auch die nützliche Eigenschaft des Zusammenführens nicht erkannt - dass es nicht kommutativ ist (das Zusammenführen eines Themenzweigs mit dem Master bedeutet nicht, dass der Master mit dem Themenzweig zusammengeführt wird).

3. Ich suche einen natürlichen Workflow

   Manchmal passieren Fehler, weil unsere Verfahren eine bestimmte Situation nicht mit einfachen Regeln erfassen. Zum Beispiel sollte ein Fix, der für frühere Releases benötigt wird, natürlich so weit stromabwärts basieren, dass er stromaufwärts in alle erforderlichen Zweige integriert werden kann (ist die Verwendung dieser Begriffe klar genug?). Es kommt jedoch vor, dass ein Fix es in den Master schafft, bevor der Entwickler erkennt, dass er weiter stromabwärts platziert werden sollte, und wenn dies bereits vorangetrieben ist (noch schlimmer, zusammengeführt oder etwas, das darauf basiert), bleibt die verbleibende Option Kirschpflücken mit die damit verbundenen Gefahren. Welche einfachen Regeln wie diese verwenden Sie?Darin ist auch die Unbeholfenheit eines Themenzweigs enthalten, der notwendigerweise andere Themenzweige ausschließt (vorausgesetzt, sie sind von einer gemeinsamen Grundlinie verzweigt). Entwickler möchten eine Funktion nicht beenden, um eine andere zu starten. Sie haben das Gefühl, dass der Code, den sie gerade geschrieben haben, nicht mehr vorhanden ist

4. Wie vermeide ich Zusammenführungskonflikte (aufgrund von Cherry-Pick)?

   Ein sicherer Weg, einen Zusammenführungskonflikt zu erzeugen, besteht darin, zwischen Zweigen zu wählen. Sie können nie wieder zusammengeführt werden. Würde das Anwenden des gleichen Commits beim Zurücksetzen (wie geht das?) In beiden Zweigen möglicherweise diese Situation lösen? Dies ist ein Grund, warum ich es nicht wage, auf einen weitgehend auf Zusammenführungen basierenden Workflow zu drängen.

5. Wie zerlegt man sich in aktuelle Zweige?

   Wir sind uns bewusst, dass es fantastisch wäre, eine fertige Integration aus Themenzweigen zusammenzustellen, aber oft ist die Arbeit unserer Entwickler nicht klar definiert (manchmal so einfach wie "Stöbern") und wenn ein Code bereits in ein "anderes" Thema eingegangen ist, es kann dort nicht wieder herausgenommen werden, gemäß der obigen Frage? Wie arbeiten Sie mit der Definition / Genehmigung / Abschluss / Freigabe Ihrer Themenbereiche?

6. Richtige Verfahren wie Codeüberprüfung und Abschluss wären natürlich sehr schön.

   Aber wir können die Dinge einfach nicht genug entwirren, um dies zu bewältigen - irgendwelche Vorschläge? Integrationszweige, Illustrationen?

Unten finden Sie eine Liste verwandter Fragen:

• Welche guten Strategien ermöglichen es, dass bereitgestellte Anwendungen Hotfixing-fähig sind?
• Workflow-Beschreibung für die Verwendung von Git für die Eigenentwicklung
• Git-Workflow für die Entwicklung von Linux-Kerneln für Unternehmen
• Wie pflegen Sie Entwicklungscode und Produktionscode? (Danke für dieses PDF!)
• Git veröffentlicht Management
• Git Cherry-Pick gegen Merge Workflow
• Wie man mehrere Commits auswählt
• Wie füge ich ausgewählte Dateien mit git-merge zusammen?
• So wählen Sie eine Reihe von Commits aus und verschmelzen zu einem anderen Zweig
• ReinH Git Workflow
• Git-Workflow zum Vornehmen von Änderungen, die Sie niemals zum Ursprung zurückschieben werden
• Wählen Sie eine Zusammenführung aus
• Richtiger Git-Workflow für kombiniertes Betriebssystem und privaten Code?
• Projekt mit Git pflegen
• Warum kann Git keine Änderungen an Merge-Dateien mit einem geänderten übergeordneten / Master ändern?
• Git Branching / Rebasing Good Practices
• Wann bringt mich "git pull --rebase" in Schwierigkeiten?
• Wie wird DVCS in großen Teams eingesetzt?

Lesen Sie auch, was Plastic SCM über die aufgabengesteuerte Entwicklung schreibt. Wenn Sie sich nicht für Plastic entscheiden, lesen Sie das Verzweigungsmodell von nvie und seine unterstützenden Skripte .

Das beunruhigendste Merkmal, das neue Entwickler von DVCS erkennen müssen, betrifft den Veröffentlichungsprozess :

• Sie können jedes benötigte Remote-Repo importieren (holen / ziehen)
• Sie können auf jedem gewünschten (nackten) Repo veröffentlichen (pushen)

Daher können Sie einige Regeln einhalten, um Ihre Fragen zu vereinfachen:

• Einen Zweig nur dann neu gründen, wenn er nicht gepusht wurde (seit dem letzten Rebase nicht gepusht)
• nur auf ein nacktes Repo drücken (obligatorisch seit Git1.7)
• Befolgen Sie die Anweisungen von Linus zu Rebase und Merges

Jetzt:

Workflows / Verzweigungsmodelle :

Jeder Workflow unterstützt einen Release-Management-Prozess , der auf jedes Projekt zugeschnitten ist.
Was ich dem von Ihnen erwähnten Workflow hinzufügen kann, ist: Jeder Entwickler sollte keinen Feature-Zweig erstellen, sondern nur einen "aktuellen Entwickler" -Zweig, denn die Wahrheit ist: Der Entwickler weiß oft nicht, was genau sein Zweig produzieren wird: einen Feature, mehrere (weil es ein zu komplexes Feature war), keines (weil es nicht rechtzeitig zur Veröffentlichung bereit war), ein anderes Feature (weil das Original "verwandelt" hatte), ...

Nur ein "Integrator" sollte offizielle Feature-Zweige in einem "zentralen" Repo einrichten, die dann von Entwicklern abgerufen werden können, um den Teil ihrer Arbeit, der zu diesem Feature passt, neu zu starten / zusammenzuführen.

Zusammenführen gegen erneutes Basieren (Wirren gegen sequentielle Geschichte) :

Ich mag meine Antwort, die Sie erwähnen (" Workflow-Beschreibung für die Verwendung von Git für die interne Entwicklung ")

Ich suche einen natürlichen Workflow :

Bei Korrekturen kann es hilfreich sein, jede Korrektur mit einem Ticket aus einer Fehlerverfolgung zu verknüpfen. Auf diese Weise kann sich der Entwickler daran erinnern, wo (dh in welchem ​​Zweig, dh in einem dedizierten Zweig "für Korrekturen") solche Änderungen vorgenommen werden sollten.
Dann können Hooks helfen, ein zentrales Repo vor Pushs vor nicht validierten Bugfixes oder vor Zweigen zu schützen, von denen aus man nicht pushen sollte. (Keine spezifische Lösung hier, all dies muss an Ihre Umgebung angepasst werden)

Wie vermeide ich Zusammenführungskonflikte (aufgrund von Cherry-Pick)?

Wie Jakub Narębski in seiner Antwort feststellte , sollte das Pflücken von Kirschen seltenen Situationen vorbehalten sein, in denen dies erforderlich ist.
Wenn Ihr Setup viel Kirschernte beinhaltet (dh "es ist nicht selten"), ist etwas nicht in Ordnung.

Würde das gleiche Commit beim Zurücksetzen angewendet (wie geht das?)

git revert sollte sich darum kümmern, aber das ist nicht ideal.

Wie zerlegt man sich in aktuelle Zweige?

Solange eine Branche noch nicht überall vertreten ist, sollte ein Entwickler seine Commit-Historie neu organisieren (sobald er / sie endlich sieht, dass die Entwicklung eine endgültigere und stabilere Form annimmt) in:

• bei Bedarf mehrere Zweige (einer nach eindeutig identifizierter Funktion)
• eine zusammenhängende Reihe von Commits innerhalb eines Zweigs (siehe Trimmen von Git-Checkins )

Richtige Verfahren wie Codeüberprüfung und Abschluss?

Integrationszweige (in einer dedizierten Integration) repo kann dem Entwickler helfen:

• seine / ihre Entwicklung auf diesen Remote-Integrationszweig zurücksetzen (pull --rebase)
• lokal lösen
• Schieben Sie die Entwicklung zu diesem Repo
• erkundigen Sie sich beim Integrator, der nicht zu einem Durcheinander führt;)

Ich denke, und ich könnte mich irren, dass eines der Dinge, die am meisten an Git missverstanden werden, seine verteilte Natur ist. Dies macht es ganz anders, Subversion in der Art und Weise zu sagen, wie Sie arbeiten können, obwohl Sie das SVN-Verhalten nachahmen können, wenn Sie möchten. Das Problem ist, dass so ziemlich jeder Workflow funktioniert, was großartig, aber auch irreführend ist.

Wenn ich die Kernelentwicklung richtig verstanden habe (ich werde mich darauf konzentrieren), hat jeder sein eigenes Git-Repository für die Entwicklung des Kernels. Es gibt ein Repository, linux-2.6.git, das von Torvalds betreut wird und als Release-Repository fungiert. Die Leute klonen von hier aus, wenn sie ein Feature für den Zweig "Release" entwickeln möchten.

Andere Repositories entwickeln sich weiter. Die Idee ist, von Linux-2.6 zu klonen und so oft zu verzweigen, wie Sie möchten, bis Sie eine funktionierende "neue" Funktion haben. Wenn dies fertig ist, können Sie es einer vertrauenswürdigen Person zur Verfügung stellen, die diesen Zweig aus Ihrem Repository in ihr Repository zieht und ihn in den Mainstream einfügt. Im Linux-Kernel geschieht dies auf mehreren Ebenen (vertrauenswürdige Leutnants), bis es Linux-2.6.git erreicht und an diesem Punkt "der Kernel" wird.

Hier wird es verwirrend. Zweigstellennamen müssen überhaupt nicht in allen Repositorys konsistent sein. So kann git pull origin master:vanilla-codeich einen Zweig vom originMaster in einem Zweig in meinem Repository namens abrufen vanilla-code. Vorausgesetzt, ich weiß, was los ist, spielt es keine Rolle - es wird in dem Sinne verteilt, dass alle Repositorys Peers miteinander sind und nicht nur auf mehreren Computern wie SVN gemeinsam genutzt werden.

Vor diesem Hintergrund:

1. Ich denke, es liegt an jedem Programmierer, wie er seine Verzweigung macht. Alles, was Sie benötigen, ist ein zentrales Repository für die Verwaltung von Releases usw. Trunk könnte sein head. Releases können Tags oder Zweige sein, und Hotfixes sind wahrscheinlich Zweige für sich. In der Tat würde ich wahrscheinlich Releases als Zweige machen, damit Sie sie weiter patchen können.
2. Ich würde fusionieren und nicht neu gründen. Wenn zum Beispiel nehmen Sie ein Repository, Klon es, Zweig und einige Entwickler tun, ziehen Sie dann von Ihrem originSie sollten in Ihrem Repository, wahrscheinlich einen anderen Zweig machen und die neuesten verschmelzen masterin yourbranchso , dass jemand anderes Ihre Änderungen mit so wenig Aufwand ziehen kann möglich. Nach meiner Erfahrung besteht sehr selten die Notwendigkeit, wirklich neu zu gründen.
3. Ich denke, es geht darum zu verstehen, wie Git funktioniert und was es kann. Es dauert eine Weile und viel gute Kommunikation - ich begann erst wirklich zu verstehen, was los ist, als ich anfing, Git mit anderen Entwicklern zu verwenden, und selbst jetzt bin ich mir bei einigen Dingen nicht sicher.
4. Zusammenführungskonflikte sind nützlich. Ich weiß, ich weiß, Sie möchten, dass alles funktioniert, aber Tatsache ist, dass sich der Code ändert und Sie die Ergebnisse zu etwas zusammenführen müssen, das funktioniert. Zusammenführungskonflikte sind in der Tat nur mehr Programmierung. Ich habe nie eine einfache Erklärung dafür gefunden, was ich dagegen tun soll. Hier ist es also: Notieren Sie sich die Dateien, bei denen Zusammenführungskonflikte auftreten, und ändern Sie sie in das, was sie sein sollten, git add .und dann git commit.
5. Wie auch immer es passt. Wie ich bereits sagte, ist das Git-Repository jedes Benutzers sein eigenes, mit dem er spielen kann, und die Namen der Zweige müssen nicht identisch sein . Wenn Sie beispielsweise über ein Staging-Repository verfügen, können Sie ein Namensschema erzwingen, müssen dies jedoch nicht für jeden Entwickler, sondern nur im Release-Repo.
6. Dies ist die Zusammenführungsphase. Sie werden nur dann in Release-Zweige usw. zusammengeführt, wenn Sie der Meinung sind, dass Code überprüft werden muss, oder wenn Sie die Qualitätsprüfung bestehen.

Ich hoffe das hilft. Mir ist klar, dass VonC gerade eine sehr ähnliche Erklärung gepostet hat ... Ich kann nicht schnell genug tippen!

Bearbeiten Sie einige weitere Gedanken zur Verwendung von Git in einer kommerziellen Umgebung, da dies aus den Kommentaren für das OP relevant erscheint:

• Das Release-Repository, wie wir es nennen product.git, ist für eine Reihe von erfahrenen Programmierern / Technikern zugänglich, die für die eigentliche Pflege des Produkts selbst verantwortlich sind. Sie sind analog zur Rolle der Betreuer in OSS.
• Diese Programmierer führen wahrscheinlich auch teilweise die Entwicklung neuer Versionen an, sodass sie sich möglicherweise selbst codieren und verschiedene Repositorys verwalten. Sie verwalten möglicherweise Staging-Repositorys für wirklich neue Funktionen und verfügen möglicherweise auch über eigene Repositorys.
• Darunter befinden sich Programmierer, die für die Entwicklung einzelner Bits verantwortlich sind. Beispielsweise könnte jemand für die UI-Arbeit verantwortlich sein. Sie verwalten daher das UI.git-Repository.
• Darunter befinden sich die eigentlichen Programmierer, die die Funktionen als ihre tägliche Aufgabe entwickeln.

Was passiert also? Nun, jeder zieht zu Beginn eines jeden Tages aus der "Upstream" -Quelle, dh dem Release-Repository (das wahrscheinlich auch das neueste Material aus der Entwicklung der vorherigen Tage enthalten wird). Jeder macht das direkt. Dies wird in einem Zweig in ihrem Repository geschehen, wahrscheinlich "Master" genannt, oder wenn Sie mich "Neueste" nennen. Der Programmierer erledigt dann einige Arbeiten. Diese Arbeit könnte etwas sein, bei dem sie sich nicht sicher sind, also machen sie einen Zweig, erledigen die Arbeit. Wenn es nicht funktioniert, können sie den Zweig löschen und zurückgehen. In diesem Fall müssen sie in den Hauptzweig übergehen, an dem sie gerade arbeiten. Wir werden sagen, dass dies ein UI-Programmierer ist, an dem latest-uier arbeitet, git checkout latest-uigefolgt vongit merge abc-ui-mywhizzynewfeature. Dann sagt er seinem technischen Leiter (dem UI-Leiter), hey, ich habe eine solche Aufgabe erledigt, zieh mich zurück. Der UI-Lead tut dies also git pull user-repo lastest-ui:lastest-ui-suchafeature-abc. Der UI-Leiter sieht es sich dann in diesem Zweig an und sagt, eigentlich ist das sehr gut, ich werde es zusammenführen ui-latest. Er könnte dann jedem unter ihm sagen, er ui-latestsolle an seinen Zweigen oder dem Namen, den sie ihnen gegeben haben, von ihm abziehen , und so wird die Funktion von den Entwicklern untersucht. Wenn das Team zufrieden ist, kann der UI-Leiter den Testleiter bitten, sich von ihm zu lösen und die Änderungen zusammenzuführen. Dies wird an alle (nach der Änderung) weitergegeben, die sie testen und Fehlerberichte usw. einreichen. Wenn die Funktion die Tests usw. besteht, wird sie möglicherweise von einem der wichtigsten technischen Leiter in die aktuelle Arbeitskopie des Programms eingefügt Alle Änderungen werden dann wieder nach unten weitergegeben. Und so weiter.

Es ist keine "traditionelle" Arbeitsweise und wurde eher als "Peer-gesteuert" als als "hierarchisch" wie SVN / CVS konzipiert. Im Wesentlichen hat jeder Commit-Zugriff, jedoch nur lokal. Es ist der Zugriff auf das Repository und das Repository, das Sie als Release-Repo festlegen, mit dem Sie die Hierarchie verwenden können.

Ein Modell, das ich mit guten Ergebnissen verwendet habe, ist das folgende:

Ein "gesegnetes" Repo, das jeder schiebt und von / zu zieht, im Grunde eine Client-Server-Topologie.

Es gibt keinen Hauptzweig, so dass kein Entwickler Code in "mainline" verschieben kann.

Alle Entwicklungen finden in Themenbereichen statt. Wir haben Namen benannt, um leicht zu erkennen, wer dafür verantwortlich ist: jn / newFeature oder jn / issue-1234

Es gibt auch eine 1: 1-Zuordnung zwischen Zweigen und Kanban / Scrum-Karten auf dem Whiteboard.

Um einen Zweig freizugeben, wird er in das gesegnete Repo geschoben und die Kanban-Karte wird zur Überprüfung bereitgelegt.

Wenn der Zweig dann von der Überprüfung akzeptiert wird, ist er ein Kandidat für eine Freigabe.

Eine Freigabe erfolgt, wenn eine Reihe akzeptierter Zweige zusammengeführt und mit einer Versionsnummer versehen werden.

Durch Verschieben des neuen Tags in das gesegnete Repo entsteht eine neue mögliche Basis für neue Funktionen.

Um Zusammenführungskonflikte zu vermeiden, werden Entwickler gebeten, ihre unveröffentlichten Zweige auf das neueste Release-Tag zu aktualisieren (zusammenzuführen).

Persönlich versuche ich, nur Release-fähigen Code in der Hauptniederlassung zu behalten.

Wenn ich an einer neuen Funktion oder einem neuen Bugfix arbeite, mache ich das in einem Zweig. Ich habe auch Unit-Test in der Branche. Wenn alles in Ordnung ist, füge ich erst dann wieder den Master hinzu.

Ich versuche auch, gängige Namenskonventionen für Zweige zu verwenden, wie z.

• bugfix / recursive_loop
• bugfix / sql_timeout
• feature / new_layout
• Feature / Enhanced_Search