Git
Analysieren von Arten von Workflows

Bemerkungen

Gitflow Workflow

Ursprünglich von Vincent Driessen vorgeschlagen, ist Gitflow ein Entwicklungsworkflow, der Git und mehrere vordefinierte Zweige verwendet. Dies kann als Sonderfall des Feature Branch Workflow betrachtet werden .

Der Grundgedanke dabei ist, separate Niederlassungen für bestimmte Teile in der Entwicklung zu reservieren:

• master ist immer der aktuellste Produktionscode . Experimenteller Code gehört nicht hierher.
• develop enthält alle neuesten Entwicklungen . Diese Entwicklungsänderungen können so ziemlich alles sein, aber größere Funktionen sind ihren eigenen Zweigen vorbehalten. Code wird hier vor der Veröffentlichung / Bereitstellung immer bearbeitet und in das release eingebunden.
• hotfix Zweige hotfix kleinere Fehlerbehebungen, die nicht bis zur nächsten Version warten können. hotfix Zweige kommen von master und werden wieder in master und develop .
• release Zweigen werden neue Entwicklungen von der develop bis zum master freigegeben. Alle Änderungen in letzter Minute, z. B. die Versionsnummern zum Bumping, werden im Release-Zweig vorgenommen und dann wieder mit master und develop . Bei der Bereitstellung einer neuen Version sollte master mit der aktuellen Versionsnummer gekennzeichnet sein (z. B. mit semantischer Versionierung ), um später darauf zurückgreifen zu können.
• feature Zweige sind für größere Features reserviert. Diese sind speziell in bestimmten Zweigen entwickelt und integriert mit der develop , wenn Sie fertig. Dedicated feature Zweige helfen Entwicklung zu trennen und done Funktionen unabhängig voneinander einsetzen zu können.

Eine visuelle Darstellung dieses Modells:

Die ursprüngliche Darstellung dieses Modells:

Workflow für die Gabelung

Diese Art von Workflow unterscheidet sich grundlegend von den anderen, die zu diesem Thema erwähnt wurden. Anstatt ein zentrales Repo zu haben, auf das alle Entwickler Zugriff haben, hat jeder Entwickler sein eigenes Repo, das vom Haupt-Repo abgezweigt wird. Der Vorteil davon ist, dass Entwickler ihre eigenen Repos anstelle eines gemeinsam genutzten Repos veröffentlichen können und ein Betreuer die Änderungen der gegabelten Repos jederzeit in das Original integrieren kann.

Eine visuelle Darstellung dieses Workflows sieht wie folgt aus:

Zentralisierter Workflow

Bei diesem grundlegenden Workflow-Modell enthält ein master Zweig alle aktiven Entwicklungen. Die Mitwirkenden müssen besonders sicher sein, dass sie die neuesten Änderungen vornehmen, bevor sie sich weiterentwickeln können, denn diese Branche wird sich schnell ändern. Jeder hat Zugriff auf dieses Repo und kann Änderungen direkt an die Hauptniederlassung übergeben.

Visuelle Darstellung dieses Modells:

Dies ist das klassische Versionskontrollparadigma, auf dem ältere Systeme wie Subversion und CVS aufgebaut wurden. Software, die auf diese Weise funktioniert, nennt man zentrale Versionskontrollsysteme (CVCS). Git ist zwar in der Lage, auf diese Weise zu arbeiten, es gibt jedoch erhebliche Nachteile, z. B. dass vor jedem Ziehen eine Zusammenführung erforderlich ist. Es ist durchaus möglich, dass ein Team auf diese Weise arbeitet, aber die ständige Konfliktlösung kann am Ende viel wertvolle Zeit kosten.

Aus diesem Grund hat Linus Torvalds Git nicht als CVCS, sondern als DVCS ( Distributed Version Control System) entwickelt , ähnlich wie Mercurial. Der Vorteil dieser neuen Vorgehensweise liegt in der Flexibilität, die in den anderen Beispielen auf dieser Seite gezeigt wird.

Funktionszweig-Workflow

Der Kerngedanke hinter dem Funktionszweiges Der Workflow ist , dass alle Feature - Entwicklung in einem speziellen Zweig nehmen sollte anstelle des master - Zweig. Diese Verkapselung erleichtert es mehreren Entwicklern, an einem bestimmten Feature zu arbeiten, ohne die Hauptcodebase zu stören. Dies bedeutet auch, dass der master Zweig niemals fehlerhaften Code enthält, was für kontinuierliche Integrationsumgebungen von großem Vorteil ist.

Durch die Verkapselung der Feature-Entwicklung können auch Pull-Anfragen genutzt werden, mit denen Diskussionen in einem Zweig initiiert werden können. Sie geben anderen Entwicklern die Möglichkeit, sich für ein Feature abzumelden, bevor es in das offizielle Projekt integriert wird. Wenn Sie mitten in einer Funktion stecken bleiben, können Sie eine Pull-Anfrage öffnen, in der Sie nach Vorschlägen Ihrer Kollegen gefragt werden. Der Punkt ist, Pull-Anfragen machen es Ihrem Team unglaublich leicht, die Arbeit des anderen zu kommentieren.

basierend auf Atlassian Tutorials .

GitHub Flow

In vielen Open Source-Projekten beliebt, aber nicht nur.

Der Master- Zweig eines bestimmten Standorts (Github, Gitlab, Bitbucket, lokaler Server) enthält die neueste lieferbare Version. Für jede neue Feature- / Fehlerbehebung / Architekturänderung erstellt jeder Entwickler einen Zweig.

Änderungen finden in diesem Zweig statt und können in einer Pull-Anfrage, Code-Überprüfung usw. besprochen werden. Nach der Annahme werden sie mit dem Hauptzweig zusammengeführt.

Voller Fluss von Scott Chacon:

• Alles in der Master-Niederlassung kann eingesetzt werden
• Um an etwas Neuem zu arbeiten, erstellen Sie einen beschreibend benannten Zweig von master (dh: new-oauth2-scope).
• Übernehmen Sie diese Verzweigung lokal und verschieben Sie Ihre Arbeit regelmäßig an dieselbe Verzweigung 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 die Funktion überprüft und abgemeldet hat, können Sie sie mit dem Master zusammenführen
• Sobald es zusammengeführt und auf "Master" verschoben wurde, können und sollten Sie es sofort implementieren

Ursprünglich auf Scott Chacons persönlicher Website präsentiert .

Bild mit freundlicher Genehmigung der GitHub Flow-Referenz