Welche Git-Verzweigungsmodelle funktionieren für Sie?

378

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

  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:

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 .

HiQ CJ
quelle
2
Hah, danke, in der Tat hat es ... Ich habe tatsächlich das meiste davon gelesen ... Zeug :-). Es ist etwas, für das ich bekannt bin - mich nicht mit der mittelmäßigen Lösung zufrieden zu geben, sondern weiter nach dem Perfekten zu suchen. Oft ist dies ein Fehler, aber in diesem Fall steht viel auf dem Spiel und die vorliegenden Lösungen sind einfach zu chaotisch oder zu schlecht, als dass ich weiter suchen müsste. Also habe ich beschlossen, alle Probleme aufzulisten, die ich damit habe.
HiQ CJ
Plastic SCM Blog warf ihre Meinung in die Diskussion, es ist zumindest aufschlussreich: codicesoftware.blogspot.com/2010/08/…
HiQ CJ
1
Sie müssen vorsichtig sein, wenn Sie "merge --no-ff" verwenden. Überprüfen Sie dies auf einige Einschränkungen. Sandofsky.com/blog/git-workflow.html
Doppelgänger
1
@Doppelganger Mich würde interessieren, wie speziell das --no-ff angeblich zu dem in dem von Ihnen geposteten Link beschriebenen Problem beiträgt. Für mich ist das beschriebene Problem das Versagen der Halbierung bei Checkpoint-Commits und das Versagen der Git-Schuld, in diesem Fall zu helfen - aber ich sehe nicht, wie "--no-ff" etwas ändert, anstatt es nicht zu verwenden. Der Autor beschwert sich darüber, dass durch das Zusammenführen mit --no-ff eine Datei nicht geändert wird. Ohne sie würde die Datei jedoch auch nicht geändert. Sie würden nur das ältere Commit in Ihrem Verlauf sehen, oder?
Codeling
Anderes Verzweigungsmodell: Kaktusmodell barro.github.io/2016/02/… , Hauptlinienmodell bitsnbites.eu/a-stable-mainline-branching-model-for-git . Diese beiden Verzweigungsmodelle bieten einen anderen Ansatz als gitflow.
Mathieu Momal

Antworten:

90

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:

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;)
VonC
quelle
@ OnkelCJ: Wie Sie sehen können, ist dies nicht genau eine endgültige Antwort auf Ihre "letzte Frage";)
VonC
Ich verstehe, und ich habe auch ein gutes Gefühl für Ironie, es ist
HiQ CJ
3
@UncleCJ Upstream ist genau der Ort, an dem Sie regelmäßig von meinem Post abrufen, wo immer alle Commits landen (die Release-Version oder der Trunk im SVN-Sprachgebrauch). Downstream ist jeder unter ihnen. Das Senden von Material im Upstream-Modus ist der Prozess, bei dem es in das Release-Repo (wie Linux-2.6) integriert wird, und im Downstream-Modus werden die Änderungen von dort oder von Ihrem Repository aus vorgenommen, wie beispielsweise der Manager, der eine solche Funktion für Ihre Minions entwickelt hat ... I. gemeines Team.
2
@UncleCJ: "Ich finde es immer noch schwierig, Ihre Checkins zu kürzen, um einen streng sequenziellen Verlauf zu erreichen": Mit Git1.7 ist es einfacher und es rebase --interactive --autosquashwerden automatisch alle Commits mit demselben Beginn einer anderen Commit-Nachricht verschoben. Wenn diese Commits eine Ticketnummer verwenden (zum Beispiel), ermöglicht der Autosquash eine schnelle Neuordnung dieser Commits, auch wenn die mit diesem Ticket verbundenen Korrekturen zu diesem Zeitpunkt nicht nacheinander vorgenommen wurden.
VonC
1
@UncleCJ: "Streng sequentieller Verlauf (ist dies erforderlich oder nicht?!)": Nicht immer erforderlich, aber es hilft, funktionale Abhängigkeiten ( stackoverflow.com/questions/881092/… ) und semantische Konflikte ( stackoverflow.com/questions ) zu verfolgen / 2514502 /… )
VonC
21

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.


quelle
Vielen Dank für Ihre ausführliche Antwort (und Ihre Stimmen). Ich werde sie noch ein paar Mal lesen, um nützliche Informationen daraus zu gewinnen. Wir sind jedoch ein Unternehmen, kein OSS-Entwicklungskomitee ;-), und ich muss meinen Entwicklern mit klareren Richtlinien helfen, als "in Ihrem eigenen Repository herumzuspielen, wie Sie wollen". Mal sehen, wohin dieser Beitrag führt, ich fühle eine gute Dynamik, mach weiter so!
HiQ CJ
@VonC Danke. @UncleCJ stimmt, aber Sie haben sicher Release-Manager usw. Jeder, der Zugriff auf das Repository hat, kann diese Dinge tun. Warum nicht den Entwicklern die Freiheit geben, sich im Rahmen der Vernunft zu verzweigen? Vorausgesetzt, Sie haben ein Protokoll zum Vereinbaren von Zusammenführungen und Ihre zentralen Repositorys werden nach Ihren Wünschen benannt, gibt es kein Problem. Trotzdem ist ein allgemeines Namensschema keine schlechte Idee. Ich neige dazu, Initialen-Version-Feature-Unterzweige für persönliche Zweige und Version für Zweige zu verwenden.
@UncleCJ Ich habe ein Beispiel hinzugefügt, wie es in einem Unternehmen funktionieren könnte. Es sind im Wesentlichen die OSS-Rollen, die durch Manager ersetzt werden, aber Sie bekommen die Idee. Es hat den zusätzlichen Vorteil gegenüber SVN, dass Ihre Entwickler auch offline arbeiten können (sie benötigen nur das Netz zum Ziehen / Schieben), und ich denke, es erleichtert das Testen von Funktionen, wenn Sie es gut implementieren.
Wow, das ist eigentlich ein großartiges Beispiel, wir könnten anfangen, so etwas für den Abschluss zu verwenden. Ich habe nicht so viel gemeint, dass wir, da wir nicht OSS machen, jeder regulieren muss, eigentlich ein ziemlich kleines und flaches Team sind, aber wir müssen versuchen, effizient nach einem engen Zeitplan zusammenzuarbeiten und auch als Team zu lernen . Deshalb stelle ich hier diese dummen Fragen, damit ich später dem Rest des Teams helfen kann :-). Ich habe auch von #git erkannt, dass eine schlecht definierte Grundlinie in Kombination mit dem Druck, die Vorlaufzeiten zu verkürzen, uns dazu bringt, auf den Beinen zu stolpern ... wir werden später zurück sein.
HiQ CJ
Das ist fair genug - ich war kürzlich dort, und genau so habe ich dieses Beispiel aufgegriffen, indem ich es ausprobiert habe und viel versagt habe ... und mich auch an die Arbeitsweise einiger OSS-Projekte angepasst habe. Ich denke, das wahre Problem ist, dass es egal ist, wie Sie sich verzweigen und wo sich Ihre Repositories befinden ... Sie können diese so definieren, wie Sie möchten, was für mich sowieso ein echter Schock war! Aber es erlaubt Ihnen, einige interessante Dinge zu tun. Wie auch immer, viel Glück und viel Spaß!
9

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).

John Nilsson
quelle
2

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
xero
quelle