Da ich oft merke, dass selbst Entwickler die eigentlich schon lange Git Flow benutzen, unsicher sind, hier ein kleiner Leitfaden für die tägliche Arbeit:
Allgemeines
Git Flow besteht im Kern aus 2 Haupt-Branches: develop und master.develop: Hier liegt der neuste Code, bereit veröffentlicht zu werdenmaster: Das hier ist live.
Zudem gibt es 3 weitere Brancharten: feature, hotfix und release
feature/PROJECT-123-my-new-feature: Wird abgezweigt von develop, hier wird ein neues Feature entwickelt oder ein Bug gefixt. Der Name besteht meist aus “feature/” gefolgt von einer Vorgangsnummer (PROJECT-123), je nach genutzter Vorgangsverwaltung (z.B. Jira, Redmine, etc.) und einer Beschreibung (my-new-feature).
Nach Fertigstellung geht es wieder zurück nach develop.
release/v1.2.3: Sobald alles für das nächste Release fertig und in develop ist, kann es gestartet werden. Es zweigt von develop ab und wird so lange getestet und gefixed, bis das Team mit der Qualität zufrieden ist. Daraufhin geht es nach master und, für die evtl. durchgeführten Fixes, auch zurück nach develop.
Jedes Release wird nach seinem Abschluss Tag versehen, so dass im nachhinein der exakte Commit des Release bestimmt werden kann. Zudem wird der Releasebranch gelöscht
hotfix/PROJECT-456-critical-bug: Wird abgezweigt von master. Wird genutzt um kritische Bugs zu beheben, für die der normale Prozess zu langsam ist. Nach einem erfolgreichen Test wird der Branch zurück nach master und auch nach develop zurückgemerged. Nach master, damit es live ist und nach develop, damit alle was davon haben (und nicht direkt wieder über den Fehler stolpern).
Wie auch bei einem Release, wird ein Hotfix nach seinem Abschluss ebenfalls getaggt, bzw. sein Branch gelöscht.
Best Practices
Ich muss eine neues Feature entwickeln/ein Bug fixen?
Für ein neues Feature (bzw. Bug) wird ein neuer Branch von develop abgezweigt, in dem die Umsetzung erfolgt. Erst wenn diese wirklich vollständig abgeschlossen ist, sollte der Branch zurück nach develop gemerged werden, da von hier jederzeit ein neues Release gestartet werden könnte und fehlerhafte oder unvollständige Features zu Problemen führen werden. Generell empfiehlt es sich, sofern man nicht alleine arbeitet, Merge Requests, bzw. Pull Requests zu benutzen.
Ich habe develop kaputt gemacht. Was nun?
Nun ist es passiert. Ein großes Feature wurde entwickelt, alle lokalen Tests waren erfolgreich und auch beim Merge Request ist nichts aufgefallen und es wurde nach develop gemerged. 1-2 Wochen läuft alles ruhig, aber kurz nach dem ein neues Release gestartet wurde, geht plötzlich nichts mehr. Was nun?
Den Bug fixen: Das wäre die einfachste Variante, aber wenn es so einfach wäre, würdest du diesen Artikel vermutlich nicht lesen, oder?
Den Merge reverten: Wenn noch nicht allzu viel Zeit verstrichen ist, kann es einen Versuch Wert sein, den Merge Commit zu reverten. Je nach Größe des Features und Eingriffe in vorhandenen Code besteht hier jedoch die Chance, erhebliche Mergekonflikte zu verursachen. Hierbei empfiehlt es sich alle Commits die nach dem Merge in develop des Features vorher in umgekehrter zeitlicher Reihenfolge ebenfalls zu reverten.
Hierbei ist noch zu beachten, das der Original-Commit nicht gelöscht wird, sondern dass ein zusätzlicher Commit erstellt wird, in dem alle Änderungen im Umsprungscommit in umgekehrter Reihenfolge angewendet werden.
Ein Beispiel: Ein Commit erzeugt in einer Datei eine neue Zeile, dann wird durch den Revert dieses Commits ein zweiter Commit angelegt in dem die Zeile gelöscht wird.
develop erneut abzweigen: Etwas radikaler, aber eigentlich recht einfach: Zu Beginn muss der lokale Branch develop gelöscht und vom letzten Commit vor dem fehlerhaften Merge Commit erneut abgezweit werden. Daraufhin können alle Commits die nichts mit dem fehlerhaften Feature zu tun haben, einzeln per cherry-pickin den neuen Branch gemerged werden. Abschließend wird der Remote-Branch develop umbenannt oder gelöscht so dass er erneut gepushed werden kann.
Hierbei ist es wichtig, dass sich alle Entwickler eine neue lokale Kopie des Branches develop auschecken, so dass sie nicht mehr auf der alten Version arbeiten