it-swarm.com.de

Welche Git-Verzweigungsmodelle funktionieren für Sie?

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

  1. Workflows/Verzweigungsmodelle

    Nachfolgend sind die drei Hauptbeschreibungen aufgeführt, die ich gesehen habe, die sich jedoch teilweise widersprechen oder nicht weit genug gehen, 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 besser

  2. Verschmelzung vs. Umbasierung (Wirren vs. sequentielle Historie)

    Sollte man pull --rebase oder warten Sie mit dem Zusammenführen zur Hauptzeile, bis Ihre Aufgabe beendet ist? Persönlich neige ich zur Verschmelzung, da dies eine visuelle Veranschaulichung darüber liefert, auf welcher Grundlage eine Aufgabe gestartet und beendet wurde, und ich bevorzuge sogar merge --no-ff für diesen 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 Zweigthemas zum Master bedeutet nicht das Zusammenführen von Master zum Zweigthemas).

  3. Ich suche einen natürlichen Workflow

    Manchmal passieren Fehler, weil unsere Verfahren mit einfachen Regeln keine bestimmte Situation erfassen. Zum Beispiel sollte ein Fix, der für frühere Releases benötigt wird, ausreichend Downstream-basiert sein, um Upstream in alle erforderlichen Zweige einbinden zu können (ist die Verwendung dieser Begriffe klar genug?). Es kommt jedoch vor, dass ein Fix es in den Master schafft, bevor der Entwickler feststellt, dass er weiter stromabwärts hätte platziert werden müssen, und wenn dies bereits vorangetrieben wird (noch schlimmer, zusammengeführt oder etwas basierend darauf), bleibt die verbleibende Option Kirschpflücken mit die damit verbundenen Gefahren. Welche einfachen Regeln verwenden Sie? Hierin ist auch die Unbeholfenheit eines Themenzweiges enthalten, die notwendigerweise andere Themenzweige ausschließt (vorausgesetzt, sie sind von einer gemeinsamen Grundlinie abgezweigt). Entwickler wollen ein Feature nicht beenden, um ein anderes zu starten. Sie fühlen, 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, um einen Zusammenführungskonflikt zu erzeugen, scheint darin zu bestehen, zwischen Zweigen zu wählen. Sie können nie wieder zusammengeführt werden. Würde die Anwendung desselben Commits in Revert (wie geht das?) In beiden Zweigen möglicherweise diese Situation lösen? Dies ist ein Grund, warum ich es nicht wage, für einen weitgehend auf Zusammenführungen basierenden Workflow zu pushen.

  5. Wie zerfällt man in topische Zweige?

    Wir sind uns bewusst, dass es fantastisch wäre, eine fertige Integration aus Zweigstellen zusammenzustellen, aber die Arbeit unserer Entwickler ist oftmals nicht klar definiert (manchmal so einfach wie "Herumstöbern") und wenn Code bereits in ein "verschiedenes" Thema eingegangen ist. es kann da nicht wieder rausgenommen werden, laut obiger frage? Wie arbeiten Sie mit dem Definieren/Genehmigen/Absolvieren/Freigeben 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 das zu schaffen - irgendwelche Vorschläge? Integrationszweige, Illustrationen?

Nachfolgend finden Sie eine Liste verwandter Fragen:

Lesen Sie auch, worüber Plastic SCM schreibt aufgabenorientierte Entwicklung , und wenn Sie sich nicht für Plastic entscheiden, lesen Sie nvies Verzweigungsmodell und sein nterstützende Skripte .

367
HiQ CJ

Das beunruhigendste Feature, das neue Entwickler von DVCS benötigen, ist das Veröffentlichungsprozess :

  • sie können jedes benötigte Remote-Repo importieren (holen/ziehen)
  • sie können auf jedem beliebigen (nackten) Repo veröffentlichen (Push)

Ab diesem Punkt können Sie einige Regeln einhalten, um Ihre Fragen zu vereinfachen:

  • einen Zweig nur wiederherstellen, wenn er nicht gepusht wurde (nicht gepusht seit der letzten Wiederherstellung)
  • nur Push to a Bare Repo (obligatorisch seit Git1.7)
  • folge Linus 'Ratschläge zu Rebase und Merge

Jetzt:

Workflows/Verzweigungsmodelle :

jeder Workflow ist dazu da, einen Release-Management-Prozess zu unterstützen , und das ist auf jedes Projekt zugeschnitten.
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 genau, was er/sie genau ist Branch wird produzieren: ein Feature, mehrere (weil es ein zu komplexes Feature war), keine (weil es nicht rechtzeitig zur Veröffentlichung fertig war), ein anderes Feature (weil das ursprüngliche "verwandelt" war), ...

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

Verschmelzung vs. Umbasierung (Wirren vs. sequentielle Historie) :

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

Ich suche einen natürlichen Workflow :

bei Fixes kann es hilfreich sein, jedes Fix mit einem Ticket aus einer Fehlerverfolgung zu verknüpfen, was dem Entwickler hilft, sich zu merken, wo (d. h. in welchem ​​Zweig, d. h. einem dedizierten Zweig "für Fixes") er/sie solche Änderungen vornehmen sollte.
Dann können Hooks helfen, ein zentrales Repo vor Pushs von nicht validierten Bugfixes oder von Zweigen zu schützen, von denen man keine Pushs durchführen sollte. (Keine spezielle Lösung, all dies muss an Ihre Umgebung angepasst werden.)

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

Wie von Jakub Narębski in seiner Antwort angegeben, sollte das Pflücken von Kirschen seltenen Situationen vorbehalten sein, in denen dies erforderlich ist.
Wenn Ihre Einrichtung viel Kirschernte erfordert (d. H. "Es ist nicht selten"), ist etwas nicht in Ordnung.

Würde das gleiche Commit in Revert anwenden (wie geht das?)

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

Wie zerfällt man in aktuelle Zweige?

Solange ein Zweig noch nicht überall vorangebracht wurde, sollte ein Entwickler seine Commit-Historie neu ordnen (sobald er/sie eine endgültigere und stabilere Form der Entwicklung sieht):

  • bei Bedarf mehrere Zweige (einer durch eindeutige Kennzeichnung)
  • eine zusammenhängende Menge von Commits innerhalb eines Zweigs (siehe Git Checkins kürzen )

Richtige Verfahren wie Code-Überprüfung und Abschluss?

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

  • seine/ihre Entwicklung auf den Zweig der Remote-Integration zurückführen (pull --rebase)
  • lokal lösen
  • Schieben Sie die Entwicklung zu diesem Repo
  • erkundigen Sie sich beim Integrator, der kein Chaos verursacht;)
89
VonC

Ich denke, und ich könnte mich irren, dass eines der Dinge, die am meisten über git missverstanden werden, seine verteilte Natur ist. Dies unterscheidet Subversion von der Art und Weise, wie Sie arbeiten können, obwohl Sie das SVN-Verhalten nachahmen können, falls Sie dies wünschen. Das Problem ist so ziemlich jeder Workflow, was großartig, aber auch irreführend ist.

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

Andere Repositorys entwickeln sich. 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 geschehen ist, können Sie es einer als vertrauenswürdig geltenden Person zur Verfügung stellen, die diesen Zweig aus Ihrem Repository in den eigenen zieht und ihn mit dem Mainstream zusammenführt. Im Linux-Kernel geschieht dies auf mehreren Ebenen (Trusted Leutnants), bis es linux-2.6.git erreicht und dann zum "Kernel" wird.

Hier wird es verwirrend. Filialnamen müssen nicht in allen Repositorys konsistent sein. Ich kann also git pull Origin master:Vanilla-code Und eine Verzweigung vom Master des Origin in einer Verzweigung in meinem Repository mit dem Namen Vanilla-code Abrufen. Vorausgesetzt, ich weiß, was los ist, spielt es keine Rolle - es wird in dem Sinne verteilt, dass alle Repositorys gleichrangig sind und nicht nur von mehreren Computern wie SVN gemeinsam genutzt werden.

In Anbetracht dessen:

  1. Ich denke, es liegt an jedem Programmierer, wie er verzweigt. Sie benötigen lediglich ein zentrales Repository für die Verwaltung von Releases usw. Der Trunk kann head sein. Releases können Tags oder Zweige sein, und Hotfixes sind wahrscheinlich Zweige für sich. Tatsächlich würde ich wahrscheinlich Releases als Zweige veröffentlichen, damit Sie sie weiterhin patchen können.
  2. Ich würde fusionieren und nicht rebase. Wenn Sie zum Beispiel ein Repository nehmen, es klonen, verzweigen und einen Entwickler ausführen, dann aus Ihrem Origin ziehen, sollten Sie in Ihrem Repository wahrscheinlich einen anderen Zweig erstellen und den neuesten master zusammenführen. in yourbranch, damit jemand anders Ihre Änderungen mit so wenig Aufwand wie möglich ziehen kann. Ich habe die Erfahrung gemacht, dass es sehr selten notwendig ist, wirklich neu zu definieren.
  3. Ich denke, es geht darum zu verstehen, wie Git funktioniert und was es kann. Es dauert eine Weile und es gibt eine Menge guter Kommunikation - ich habe erst richtig verstanden, was los ist, als ich anfing, Git mit anderen Entwicklern zu verwenden, und selbst jetzt sind mir einige Dinge nicht sicher.
  4. Zusammenführungskonflikte sind nützlich. Ich weiß, ich weiß, Sie möchten, dass alles funktioniert, aber die 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 noch nie eine einfache Erklärung dafür gefunden, was ich dagegen tun soll. Beachten Sie die Dateien, bei denen Konflikte aufgetreten sind, und ändern Sie sie in die gewünschten Werte (git add . Und dann git commit.
  5. Es passt jedoch. Wie ich bereits sagte, ist jedes Benutzer-Git-Repository für sich 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, dies ist jedoch nicht für jeden Entwickler erforderlich, sondern nur für das Release-Repository.
  6. Dies ist die Zusammenführungsphase. Sie verschmelzen nur dann zu Release-Zweigen usw., wenn Sie davon ausgehen, dass der Code überprüft wird oder die Qualitätsprüfung besteht.

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

Bearbeiten Weitere Überlegungen zur Verwendung von Git in einer kommerziellen Umgebung, da dies aus den Kommentaren für das OP relevant erscheint:

  • Das Release-Repository, wir nennen es product.git, Ist für eine Reihe von erfahrenen Programmierern/Technikern zugänglich, die für die eigentliche Pflege des Produkts verantwortlich sind. Sie entsprechen der Rolle von Betreuern in OSS.
  • Diese Programmierer führen wahrscheinlich auch teilweise die Entwicklung neuer Versionen durch, sodass sie sich selbst codieren und verschiedene Repositorys verwalten können. Sie können Staging-Repositorys für wirklich neue Funktionen verwalten und über eigene Repositorys verfügen.
  • Darunter befinden sich Programmierer, die für die Entwicklung einzelner Bits verantwortlich sind. Zum Beispiel 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 für ihre tägliche Arbeit entwickeln.

Also was passiert Nun, jeder bezieht sich zu Beginn eines jeden Tages auf die "Upstream" -Quelle, d. H. Das Release-Repository (das wahrscheinlich auch das neueste Material aus der Entwicklung des Vortages enthält). Jeder macht das direkt. Dies wird in einem Zweig in ihrem Repository gespeichert, wahrscheinlich "master" oder vielleicht, wenn Sie mich "latest" nennen. Der Programmierer erledigt dann einige Arbeiten. Diese Arbeit ist vielleicht etwas, bei dem sie sich nicht sicher sind, also machen sie einen Zweig, machen die Arbeit. Wenn es nicht funktioniert, können sie den Zweig löschen und zurückgehen. Wenn dies der Fall ist, müssen sie in dem Hauptzweig zusammengeführt werden, an dem sie gerade arbeiten. Wir werden sagen, dies ist ein UI-Programmierer, der an latest-ui Arbeitet, also macht er git checkout latest-ui Gefolgt von git merge abc-ui-mywhizzynewfeature. Dann teilt er seinem technischen Leiter (dem UI-Leiter) mit, hey, ich habe eine solche Aufgabe erledigt, zieh mich zurück. Der Benutzeroberflächen-Lead führt also git pull user-repo lastest-ui:lastest-ui-suchafeature-abc Aus. Der Benutzeroberflächen-Lead sieht es sich dann auf diesem Zweig an und sagt, dass es sehr gut ist, ich werde es in ui-latest Zusammenführen. Er könnte dann jedem unter ihm sagen, er solle an seinen ui-latest - Zweigen oder an dem Namen, den sie ihnen gegeben haben, von ihm ziehen, und so wird die Funktion von den Entwicklern untersucht. Wenn das Team zufrieden ist, fordert der Benutzeroberflächenleiter möglicherweise den Testleiter auf, sich von ihm zu lösen und die Änderungen zusammenzuführen. Dies überträgt sich auf alle (nach der Änderung), die sie testen und Fehlerberichte usw. einreichen. Wenn die Funktion den Test usw. besteht, wird sie möglicherweise von einem der wichtigsten technischen Leads in der aktuellen Arbeitskopie des Programms zusammengeführt Alle Änderungen werden dann wieder nach unten übertragen. Und so weiter.

Es handelt sich nicht um eine "traditionelle" Arbeitsweise, sondern um eine "Peer-orientierte" und keine "hierarchische" Arbeitsweise wie SVN/CVS. Im Wesentlichen hat jeder Zugriff, jedoch nur lokal. Es ist der Zugriff auf das Repository und das von Ihnen als Release-Repository festgelegte Repository, mit dem Sie die Hierarchie verwenden können.

21
user257111

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

Ein "gesegnetes" Repo, das jeder pusht und zieht, im Grunde genommen eine Client-Server-Topologie.

Es gibt keine Hauptniederlassung, so dass kein Entwickler Code in die Hauptniederlassung verschieben kann.

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

Es gibt auch eine nahezu 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 zur Überprüfung bereit gestellt.

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

Eine Freigabe erfolgt, wenn mehrere akzeptierte Zweige zusammengeführt und mit einer Versionsnummer versehen werden.

Indem Sie das neue Tag auf das gesegnete Repo schieben, gibt es 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).

9
John Nilsson

Persönlich versuche ich, nur releasefähigen Code in der Hauptniederlassung aufzubewahren.

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

Ich versuche auch, gebräuchliche Namenskonventionen für Zweige zu verwenden, wie zum Beispiel:

  • bugfix/recursive_loop
  • bugfix/sql_timeout
  • feature/new_layout
  • feature/enhanced_search
2
xero