Feature Branches
Die Grundidee hinter dem Arbeiten mit Feature Branches ist, dass die
Entwicklung von Features in einem eigens dafür erstellten Branch und
nicht im Hauptbranch (Master) stattfinden sollte. Diese Einkapselung
verhindert, dass durch die Arbeiten an einem bestimmten Feature das
System nicht auslieferungsfähig ist. Vorm Ausliefern in Test- oder
Kundensysteme kann bestimmt werden, welche Features auszuliefern sind
und welche nicht.
Wie grundsätzlich mit verschiedenen Branches in einem Repository zu arbeiten ist, gibt es hier.
Feature Branches mit GIT und VS Code
Da für jedes Feature ein eigener Branch erzeugt wird, existieren in einem Repository viele Branches zur selben Zeit. Der dadurch sehr komplex werdende Commit Verlauf kann es schwierig machen, zu bestimmen, zu welchem Feature einzelne Commits und Merge Commits gehören.
Um die Git Historie einfach und übersichtlich zu halten, sind folgende Einstellungen und Abläufe zu berücksichtigen.
Grundvoraussetzungen
- Es muss mindestens die Git Version 1.7.9 installiert sein. Über
git --versionkann die aktuell installierte Version beauskunftet werden. - Beim Abrufen ist nur git Pull Rebase zu nutzen. Über
git config --global pull.rebase truewird global eingestellt, dass bei jedem Pull im Hintergrund Pull Rebase ausgeführt wird. Beim "normalen" Entwickeln und Abrufen kann genaus gearbeitet werden wie bisher.
Feature Branch erzeugen
Vor der Erzeugung des Feature Branch sollte der Hauptbranch auf dem aktuellen Stand sein.
Git Graph: 
Terminal: git branch FEATUREBRANCHNAME ->Feature Branch lokal
erstellen
git checkout FEATUREBRANCHNAME -> Branch wechseln
Durch die Ausführung dieses Befehls wird lokal ein neuer Branch angelegt. Als FEATUREBRANCHNAME ist z. B. die Ticketnummer zu verwenden. Erst wenn eine Änderung auf dem Feature Branch gepushed wird, existiert der Branch auch auf dem Server und ist über Azure DevOps einsehbar.
Das Feature kann nun innerhalb des neuen Branches mit beliebig vielen Commits entwickelt werden. Den einzelnen Commits ist eine sprechende Commit Message zu geben. Es sollte erkennbar sein, dass die Commits zu dem Feature Branch gehören. Da der Feature Branch nach Abschluss des Features wieder gelöscht wird, sollte die Ticketzuordnung erst beim Merge in den Hauptbranch erfolgen.
Zur Sicherung des Codes sollten die Commits regelmäßig auf den Server gepused werden.
Commits im Feature Branch zusammenfassen
Es ist zu empfehlen, die Commits innerhalb des Feature Branches regelmäßig zu einem Commit zusammenzufassen. Dadurch wird der Merge am Ende einfacher und die Versionshistorie übersichtlicher. Außerdem kann es praktisch sein, wenn zu einem Feature lediglich ein oder zwei Commits gehören. Das Zusammenfassen von Commits darf nur in Feature Branches erfolgen.
Git Graph:
Terminal: git merge-base FEATUREBRANCHNAME HAUPTBRANCHNAME ->
Ermittelt die Commit ID des letzten Commits, der auch im Hauptbranch
git rebase -i (git merge-base FEATUREBRANCHNAME HAUPTBRANCHNAME) ->
Gibt eine Liste aller Commits aus, die nur zum Feature gehören
Wenn die VS Code Extension GitLens installiert ist, öffnet dieser Befehl
folgende Übersicht.
Dort sollte der unterste Commit auf reword gestellt werden. Alle
anderen Commits aus dem Feature Branch müssen auf fixup
stehen. Diese Befehle sagen aus, dass die beiden Commits zu einem
zusammengeführt werden sollen und eine neue Commit Message vergeben
wird. Folgende Datei öffnet sich, in der eine neue Commit Message in die
ersten Zeile einzutragen ist. Wenn nun die Datei gespeichert und
geschlossen wird, sind die Commits zusammengeführt.
Feature Branch mit Hauptbranch aktualisieren
Gerade bei größeren Features, die über eine längere Zeit entwickelt werden, ist es sinnvoll hin und wieder den Feature Branch mit dem Stand des Hauptbranches zu aktualisieren. Spätestens ist dieser Schritt aber vor dem zurückmergen in den Hauptbranch notwendig.
Innerhalb dieses Schritts können die Commits, die man während der Feature Entwicklung gemacht hat, zu einem Commit zusammengefasst werden. Nach dem Zusammenführen von Feature Branch und Hauptbranch gehört dann lediglich ein Commit zu dem Feature.
Git Graph:
Terminal: git checkout DEV-> Wechsel in den DEV Branch
git pull -> Aktuellen Stand abrufen
git checkout FEATUREBRANCHNAME -> Wechsel in den Feature Branch
git rebase DEV -> Featurecommits werden auf Basis des aktuellen
DEVs neu erstellt
git push origin FEATUREBRANCHNAME --force -> Abgeänderte Commits
zum Server hochladen
Hauptbranch und Feature Branch zusammenführen
Wenn das Feature komplett fertig entwickelt ist, muss der Feature Branch in den Hauptbranch zurückgeführt werden.
Voraussetzung dafür ist, dass der Feature Branch alle aktuellen Änderungen aus dem Hauptbranch enthält. Probleme, wie doppelt vergebene Objektnummern, sind im Feature Branch zu lösen. Der Hauptbranch soll nämlich zu jedem Zeitpunkt release- oder auslieferungsfähig sein.
Deshalb muss vor dem Zurückführen der Feature Branch auf den aktuellen Stand gebracht werden. (siehe Feature Branch aktualisieren)
Nachdem der Feature Branch aktualisiert wurde, muss die App neu kompiliert und getestet werden. Damit ist sicherzustellen, dass keine Änderung aus dem Hauptbranch das neue Feature beeinträchtigt.
Folgende Befehle führen den Feature Branch und den Hauptbranch zusammen und löschen den Feature Branch.
**Git Graph:
Terminal: git checkout DEV -> Wechsel in den DEV Branch
git rebase FEATUREBRANCHNAME -> Stand mit rebase in den DEV Branch
bringen
git push -> Änderungen hochladen
Konflikt beim Rebase
Nachdem git rebase Befehl kann es passieren, dass Merge Konflikte auftreten. Nachdem die Konflikte behoben sind, müssen die betroffenen Dateien gestaged werden. Wenn alle Dateien gestaged sind, wird der Merge Prozess mit folgendem Befehl abgeschlossen.
git rebase --continue
Die sich danach öffnende COMMIT_EDITMSG Datei kann ohne Anpassungen
geschlossen werden. Ggf. kann es nach dem git rebase --continue zu
weiteren Merge Konflikten kommen, die genauso zu behandeln sind.
Rebase und Merge
Was unterscheidet Rebase und Merge?
Die Befehle merge und rebase werden genutzt, um Änderungen aus zwei Branches zusammenzuführen.
Der wichtigste Unterschied zwischen den Befehlen ist, dass beim Rebase die Commits aus meinem Feature Branch intern neu generiert werden. Die alten Commits aus dem Feature Branch werden tatsächlich gelöscht und neu erstellt. In der Git Commit Historie erkennen wir das dadurch, dass die Commits aus dem Feature Branch eine neue Commit ID bekommen haben.
Bei Ausführung des Merge Befehls werden keine bestehenden Commits abgeändert, sondern es wird ein neuer Commit erzeugt. In diesem Commit sind dann die Änderungen aus dem Basisbranch enthalten.
Mehr zum Thema merge und rebase findet man hier 5.
Wann nutze ich grundsätzlich merge und wann rebase?
Rebase ist nur in Verbindung mit Feature Branches zu nutzen. Also dann, wenn Commits von einem Feature Branch in den DEV gebracht werden sollen oder der Feature Branch aktualisiert werden soll.
Sobald ich Commits aus einem dauerhaft bestehenden Branch in einen anderen dauerhaft bestehenden Branch bringen möchte, ist merge zu verwenden.
Der Grund dafür ist, dass die bestehenden Commits beim Rebase abgeändert werden. Commits mit Ticketzuordnung werden beim Abändern der Commits dem Ticket erneut zugewiesen.
Dadurch wären dann mehrere inhaltlich gleiche Commits einem Ticket zugeordnet.
Außerdem müssen die abgeänderten Commits mit Force Push in den Server Branch gebracht werden. Da mit Force Push Commits dauerhaft gelöscht werden können, sollte dieser Befehl auf dauerhaft bestehende Commits nicht angewendet werden dürfen.
Pull requests
Pull Request werden verwendet um Code von einem Branch in einen anderen zu übernehmen. Dazu kann innerhalb Azure DevOps eine Pull Request erstellt werden, in dem der zu übernehmende Branch ausgewählt wird. Nach eingehender Prüfung, wahlweise durch Dritte, wird dieser in den Ziel-Branch zusammengeführt.
