5 Git-Workflows und Verzweigungsstrategien, mit denen Sie Ihren Entwicklungsprozess verbessern können
Ich habe noch keinen Entwickler getroffen, der sich beim Anblick einer Konfliktmeldung nicht frustriert die Haare raufte.
Der Versuch, jeden Merge-Konflikt zu lösen, gehört zu den Dingen, die jeder Entwickler hasst. Vor allem, wenn es Sie trifft, während Sie sich auf einen Produktionseinsatz vorbereiten!
Hier kann der richtige Git-Workflow eine Menge Gutes für Ihren Entwicklungsworkflow tun.
Natürlich wird der richtige Git-Workflow nicht alle Ihre Probleme lösen. Aber es ist ein Schritt in die richtige Richtung. Schließlich ist es für jedes Team, das remote arbeitet, von entscheidender Bedeutung, Funktionen gemeinsam zu erstellen, ohne dass Ihre Codebasis gestört wird.
Wie Sie ihn einrichten, hängt von dem Projekt ab, an dem Sie arbeiten, von den Veröffentlichungsplänen Ihres Teams, von der Größe des Teams und von vielem mehr!
In diesem Artikel gehen wir mit Ihnen 5 verschiedene Git-Workflows durch, ihre Vorteile, ihre Nachteile und wann Sie sie verwenden sollten. Legen wir los!
Basischer Git-Workflow
Der einfachste Git-Workflow ist der, bei dem es nur einen Zweig gibt – den Master-Zweig. Entwickler übertragen direkt in diesen Zweig und verwenden ihn für die Bereitstellung in der Staging- und Produktionsumgebung.
Dieser Workflow wird normalerweise nicht empfohlen, es sei denn, Sie arbeiten an einem Nebenprojekt und wollen schnell loslegen.
Da es nur einen Zweig gibt, gibt es hier wirklich keinen Prozess. Das macht es mühelos, mit Git anzufangen. Einige Nachteile, die Sie bei der Verwendung dieses Workflows beachten müssen, sind jedoch:
- Die Zusammenarbeit am Code führt zu zahlreichen Konflikten.
- Die Wahrscheinlichkeit, dass fehlerhafte Software in die Produktion geht, ist höher.
- Die Pflege von sauberem Code ist schwieriger.
Git-Feature-Branch-Workflow
Der Git-Feature-Branch-Workflow wird zu einem Muss, wenn mehr als ein Entwickler an der gleichen Codebasis arbeitet.
Stellen Sie sich vor, Sie haben einen Entwickler, der an einem neuen Feature arbeitet. Und einen anderen Entwickler, der an einem zweiten Feature arbeitet. Wenn nun beide Entwickler aus dem gleichen Zweig arbeiten und Commits hinzufügen, würde das die Codebasis zu einem riesigen Chaos mit vielen Konflikten machen.
Um dies zu vermeiden, können die beiden Entwickler zwei separate Zweige vom Master-Branch erstellen und einzeln an ihren Features arbeiten. Wenn sie mit ihrem Feature fertig sind, können sie dann ihren jeweiligen Zweig mit dem Master-Zweig zusammenführen und bereitstellen, ohne auf die Fertigstellung des zweiten Features warten zu müssen.
Die Vorteile dieses Workflows sind, dass der Git-Feature-Branch-Workflow die Zusammenarbeit am Code ermöglicht, ohne dass man sich um Code-Konflikte sorgen muss.
Git-Feature-Workflow mit Develop Branch
Dieser Workflow ist einer der beliebteren Workflows unter Entwicklerteams. Er ähnelt dem Git-Feature-Workflow mit einem Entwicklungszweig, der parallel zum Master-Zweig hinzugefügt wird.
In diesem Workflow spiegelt der Master-Zweig immer einen produktionsbereiten Zustand wider. Wann immer das Team in die Produktion deployen möchte, wird es vom Master-Zweig aus deployt.
Der Entwicklungszweig spiegelt den Zustand mit den letzten Entwicklungsänderungen für die nächste Version wider. Die Entwickler erstellen Zweige aus dem Entwicklungszweig und arbeiten an neuen Funktionen. Sobald das Feature fertig ist, wird es getestet, mit dem develop-Zweig zusammengeführt, mit dem Code des develop-Zweigs getestet, falls es eine vorherige Zusammenführung gab, und dann mit dem master-Zweig zusammengeführt.
Der Vorteil dieses Workflows ist, dass er es den Teams erlaubt, neue Features konsistent zusammenzuführen, sie im Staging zu testen und in die Produktion zu bringen. Während die Pflege des Codes einfacher ist, kann es für manche Teams etwas ermüdend werden, da es sich wie ein langwieriger Prozess anfühlen kann.
Gitflow Workflow
Der Gitflow Workflow ist dem vorher besprochenen Workflow sehr ähnlich, kombiniert mit zwei weiteren Zweigen – dem Release-Zweig und dem Hot-Fix-Zweig.
Der Hot-Fix-Zweig
Der Hot-Fix-Zweig ist der einzige Zweig, der aus dem Master-Zweig erstellt und direkt mit dem Master-Zweig zusammengeführt wird, anstatt mit dem Entwicklungszweig. Er wird nur verwendet, wenn Sie schnell ein Produktionsproblem patchen müssen. Ein Vorteil dieses Zweiges ist, dass Sie ein Produktionsproblem schnell einspielen können, ohne den Arbeitsablauf anderer zu stören oder auf den nächsten Release-Zyklus warten zu müssen.
Wenn der Fix in den Master-Zweig zusammengeführt und eingespielt ist, sollte er sowohl in den Entwicklungszweig als auch in den aktuellen Release-Zweig eingebunden werden. Das wird gemacht, um sicherzustellen, dass jeder, der vom Entwicklungszweig abzweigt, um einen neuen Funktionszweig zu erstellen, den neuesten Code hat.
Der Veröffentlichungszweig
Der Veröffentlichungszweig wird vom Entwicklungszweig abgezweigt, nachdem alle für die Veröffentlichung geplanten Funktionen erfolgreich in den Entwicklungszweig eingebunden wurden.
Im Veröffentlichungszweig wird kein Code hinzugefügt, der mit neuen Funktionen zu tun hat. Nur Code, der sich auf das Release bezieht, wird in den Release-Zweig hinzugefügt. Zum Beispiel werden Dokumentation, Fehlerkorrekturen und andere Aufgaben, die sich auf diese Version beziehen, zu diesem Zweig hinzugefügt.
Wenn dieser Zweig mit dem Master-Zweig zusammengeführt und in Produktion gegeben wird, wird er auch wieder in den Entwicklungszweig zurückgeführt, so dass, wenn eine neue Funktion aus dem Entwicklungszweig geforkt wird, er den neuesten Code hat.
Dieser Workflow wurde erstmals von Vincent Driessen veröffentlicht und populär gemacht und wird seither von Organisationen mit einem geplanten Release-Zyklus verwendet.
Da git-flow ein Wrapper um Git ist, können Sie git-flow in Ihrem aktuellen Repository installieren. Es ist ein unkomplizierter Prozess und es ändert nichts an Ihrem Repository, außer dass es Zweige für Sie erstellt.
Um auf einem Mac-Rechner zu installieren, führen Sie brew install git-flow in Ihrem Terminal aus.
Um auf einem Windows-Rechner zu installieren, müssen Sie git-flow herunterladen und installieren. Nach der Installation führen Sie den folgenden Git-Befehl git flow init aus, um ihn in Ihrem Projekt zu verwenden.
Git Fork Workflow
Der Fork-Workflow ist bei Teams, die Open-Source-Software verwenden, sehr beliebt.
Der Ablauf sieht normalerweise so aus:
- Der Entwickler forkt das offizielle Repository der Open-Source-Software. Eine Kopie dieses Projektarchivs wird in seinem Konto erstellt.
- Der Entwickler klont dann das Projektarchiv von seinem Konto auf sein lokales System.
- Ein entfernter Pfad für das offizielle Projektarchiv wird dem Projektarchiv hinzugefügt, das auf das lokale System geklont wird.
- Der Entwickler erstellt einen neuen Funktionszweig in seinem lokalen System, nimmt Änderungen vor und überträgt sie.
- Diese Änderungen werden zusammen mit dem Zweig in die Kopie des Repositorys des Entwicklers in seinem Konto übertragen.
- Eine Pull-Anfrage aus dem Zweig wird für das offizielle Repository geöffnet.
- Der Manager des offiziellen Repositorys prüft die Änderungen und genehmigt sie, um sie in das offizielle Repository einzubinden.
Automatisierung Ihrer Git-Workflows und Verzweigungsstrategie für eine bessere Produktivität
Eines der Dinge, mit denen Entwickler ständig jonglieren müssen, ist die Aktualisierung ihres Projektmanagement-Tools, um ihre Teamkollegen auf dem Laufenden zu halten. Deshalb automatisieren unsere Entwickler bei Zepel ihre Arbeitsabläufe, damit sie mehr Zeit für die Entwicklung der Software aufwenden können.
Hier sehen Sie, wie wir unseren Git-Workflow automatisieren, damit alle auf dem gleichen Stand bleiben:
Während Zepel tief in GitHub, Bitbucket und GitLab integriert ist, verwenden wir GitHub intern. Sobald wir also GitHub mit Zepel integriert haben, richtet unser Entwicklungsteam die Git-Workflow-Automatisierung innerhalb von Zepel ein. So sieht es heute aus:
Wenn Entwickler Fortschritte machen, erhält unser Team automatisch eine Slack-Benachrichtigung und ihre Änderungen werden in der User Story aufgezeichnet.
Ihre eigene Workflow- und Git-Branching-Strategie!
Die Git-Workflows, die ich in diesem Artikel gezeigt habe, sind Beispiele für einige der beliebtesten und am besten funktionierenden Workflows für das Entwicklerteam. Einige Teams erstellen einen Zweig für Staging und es funktioniert perfekt für sie.
Wenn Sie andere Workflows verwenden, die für Sie gut funktionieren, tweeten Sie uns @getzepel. Wir würden sie gerne vorstellen!
Hilfreiche Artikel
Vikash KoushikThe Zepel Blog 
Ranjali RoyThe Zepel Blog 
Ranjali RoyThe Zepel Blog 