Branches zusammenführen — was es ist, Zusammenführungsmethoden und Konfliktlösung

Was ist ein Merge in Git

Ein Merge in Git ist die Operation, zwei oder mehr Entwicklungsverläufe zu einem zu kombinieren. Wenn ein Entwickler einen Branch merged, findet Git automatisch den gemeinsamen Vorfahren (Base Commit) und erstellt einen neuen Merge-Commit, der die Änderungen aus beiden Branches enthält. Three-way Merge ist der Standardalgorithmus, der drei Zustände vergleicht: den gemeinsamen Vorfahren, den ersten Branch und den zweiten Branch.

Der Merge-Prozess beginnt mit dem Befehl git merge. Git bestimmt den Punkt, an dem die Branches auseinandergelaufen sind, und wendet die Änderungen nacheinander vom Quellbranch auf den Zielbranch an. Wenn die Änderungen nicht in Konflikt stehen, führt Git abhängig von den Einstellungen einen Fast-Forward durch oder erstellt einen Merge-Commit. Fast-Forward ist ein Szenario, bei dem der Zielbranch einfach auf die Commits des Quellbranches verschoben wird.

# Zum Zielbranch wechseln und zusammenführen
git checkout main
git merge feature/payment-module

# Mit explizitem no-fast-forward zusammenführen
git merge --no-ff feature/payment-module

# Merge abbrechen, wenn Konflikte zu komplex sind
git merge --abort

Das Flag --no-ff (no fast-forward) erzwingt die Erstellung eines Merge-Commits, selbst wenn ein Fast-Forward möglich ist. Dies bewahrt die Information, dass die Änderungen in einem separaten Branch vorgenommen wurden. Viele Teams bevorzugen diesen Ansatz, um die Branching-Historie explizit zu erhalten.

Methoden der Branch-Zusammenführung

Git hat drei Hauptstrategien für die Branch-Zusammenführung, die jeweils für ein bestimmtes Szenario geeignet sind. Die Wahl der Strategie hängt von der Teamkultur und den Anforderungen an die Sauberkeit der Projekthistorie ab.

Standard Merge erstellt einen Merge-Commit mit zwei Eltern. Die vollständige Historie bleibt erhalten, aber der Branching-Graph wird komplexer. Squash Merge fasst alle Commits eines Feature-Branches in einem zusammen und wendet ihn auf den Zielbranch an — die Historie wird linear und sauber, aber Informationen über Zwischenschritte gehen verloren.

Rebase, obwohl kein vollwertiger Merge, erzielt dasselbe Ergebnis — Änderungen eines Branches werden auf einen anderen verschoben. Der Unterschied besteht darin, dass die Historie umgeschrieben wird: Die Commits des Feature-Branches werden über dem letzten Commit des Zielbranches neu erstellt. Dies ergibt eine perfekt lineare Historie, erfordert aber beim Pushen einen Force Push.

Wie man Merge-Konflikte löst

Ein Merge-Konflikt entsteht, wenn dieselben Zeilen einer Datei in zwei Branches geändert wurden. Git kann nicht automatisch bestimmen, welche Version beibehalten werden soll, und benötigt das Eingreifen des Entwicklers. Konflikte werden in Dateien mit speziellen Markern angezeigt: <<<<<<<, =======, >>>>>>>.

Der Konfliktlösungsprozess umfasst mehrere Schritte. Zunächst öffnet der Entwickler die konfliktbehaftete Datei und wählt manuell die erforderlichen Änderungen aus. Es ist wichtig, nicht einfach eine Version auszuwählen, sondern die Logik beider Änderungen zu verstehen und eine korrekte Entscheidung zu treffen. Nach der Bearbeitung der Datei werden die Konfliktmarker entfernt und die Änderungen über git add zur Staging-Area hinzugefügt.

# Liste der konfliktbehafteten Dateien anzeigen
git status

# Mergetool starten (z. B. VS Code, IntelliJ)
git mergetool

# Nach Auflösung aller Konflikte
git add .
git merge --continue

# Oder den Merge vollständig abbrechen
git merge --abort

Die Verwendung visueller Merge-Tools beschleunigt die Konfliktlösung erheblich. VS Code, IntelliJ IDEA und GitKraken bieten Schnittstellen mit drei Bereichen: aktueller Branch, eingehender Branch und Ergebnis. Das Tool git mergetool öffnet automatisch den konfigurierten Editor für jede konfliktbehaftete Datei.

Der beste Weg, komplexe Konflikte zu vermeiden, ist die regelmäßige Synchronisation des Feature-Branches mit dem Hauptbranch. Wenn ein Entwickler einmal täglich main in seinen Branch merged, werden die Konflikte klein und leicht lösbar sein. Das Ansammeln von Änderungen über eine Woche garantiert komplexe Konflikte mit hohem Fehlerrisiko.

Wann man Rebase statt Merge verwendet

Rebase und Merge sind zwei Arten, Änderungen zu kombinieren, und die Wahl zwischen ihnen führt in Teams oft zu Diskussionen. Rebase verschiebt Commits von einem Branch auf einen anderen und schreibt dabei die Historie um. Merge erstellt einen neuen Merge-Commit und bewahrt die Branching-Historie. Jeder Ansatz hat seine Vor- und Nachteile.

Rebase ist geeignet, wenn ein Entwickler in seinem lokalen Feature-Branch arbeitet und vor der Erstellung eines Pull Request eine saubere lineare Historie wünscht. Nach dem Rebase werden alle Commits ohne unnötige Merge-Commits sequenziell angeordnet. Allerdings erfordert Rebase einen Force Push und ist nicht auf Branches anwendbar, an denen mehrere Personen gleichzeitig arbeiten.

• Rebase — für persönliche Feature-Branches, wo eine saubere Historie benötigt wird
• Merge — für gemeinsame Branches und zur Aufzeichnung des Merge-Zeitpunkts
• Squash — wenn ein Feature-Branch viele kleine Entwurfs-Commits enthält

Die goldene Regel von Git: Verwende Rebase nicht auf Commits, die bereits in das gemeinsame Repository gepusht wurden. Dies stellt sicher, dass die Historie im gemeinsamen Branch unverändert bleibt und andere Entwickler keine doppelten oder verlorenen Commits vorfinden. Zur Integration eines Feature-Branches in den Hauptbranch verwende Merge über Pull Request.

Beste Praktiken für Branch-Zusammenführung

Ein korrekter Merge-Prozess ist die Grundlage stabiler Entwicklung. In der modernen Teamarbeit wird der Merge nicht über die Konsole, sondern über Pull Request auf GitHub oder Merge Request in GitLab durchgeführt. Ein PR durchläuft Code-Review, automatische CI-Prüfungen und wird erst danach in den Hauptbranch gemerged.

Die erste Praxis — nur mergen, wenn alle Prüfungen bestanden sind. Die CI-Pipeline sollte das Projekt bauen, Tests ausführen und die Codequalität überprüfen. Wenn auch nur eine Prüfung fehlschlägt, wird der Merge blockiert. Moderne Plattformen (GitHub, GitLab) haben integrierten Schutz: Branch Protection Rules blockieren automatisch den Merge bei CI-Fehlschlägen.

Die zweite Praxis — niemals kaputten Code mergen. Vor dem Merge muss der Entwickler sicherstellen, dass seine Änderungen den Build nicht beschädigen und keine vorhandene Funktionalität beeinträchtigen. Dafür gibt es automatische Tests und Code-Review.

Die dritte Praxis — Feature-Branches nach dem Merge bereinigen. Ein Branch, der bereits gemerged wurde, sollte gelöscht werden. Dies verhindert Verwirrung und Unordnung im Repository. GitHub bietet automatisch an, einen Branch nach dem Merge eines PR zu löschen, und die Repository-Einstellungen können für automatisches Löschen konfiguriert werden.