Merge — was es ist, Zusammenführungsarten und Funktionsweise

Was ist Merge?

Merge (Zusammenführung) ist eine fundamentale Operation in Git, die Änderungen aus einem Branch (Quelle) in einen anderen (Ziel) zusammenführt. Als Ergebnis der Zusammenführung erhält der Ziel-Branch alle Commits aus dem Quell-Branch, die noch nicht in ihm vorhanden waren. Je nach Situation kann Git den Merge auf drei verschiedene Arten durchführen.

Der Hauptwert von Merge liegt in der Bewahrung der Historie: Der Merge-Commit zeichnet die Tatsache der Branch-Zusammenführung auf und bewahrt Informationen darüber, wann und welche Branches zusammengeführt wurden. Dies erleichtert die Änderungsprüfung, die Suche nach Regressionen und das Verständnis der Entwicklungschronologie. In großen Projekten ist der Merge-Commit der Standardweg der Code-Integration.

Laut GitLab Flow werden Merge-Commits in 73% der Teams verwendet, die mit Git arbeiten. Alternative Ansätze (Rebase, Squash) werden von Teams bevorzugt, die auf lineare Historie ausgerichtet sind. Die Strategiewahl hängt von der Teamgröße, der Release-Häufigkeit und den im Projekt akzeptierten Konventionen ab.

Wann Merge auftritt

Merge ist erforderlich, wenn ein Entwickler die Arbeit an einer Funktion abgeschlossen hat und sie in develop oder main integrieren möchte. Ein typisches Szenario: Ein Entwickler hat einen Feature-Branch von develop erstellt, mehrere Tage daran gearbeitet, und in dieser Zeit sind neue Commits von anderen Teammitgliedern in develop erschienen. Vor der Zusammenführung müssen die Änderungen kombiniert werden — und dafür wird Merge verwendet.

Ohne Merge ist es unmöglich, kollaborativ an einer Codebasis in Git zu arbeiten. Jedes Mal, wenn zwei Entwickler gleichzeitig Änderungen an einer Codebasis vornehmen, weichen ihre Branches voneinander ab. Merge ist die einzige Möglichkeit, diese Änderungen ohne Datenverlust wieder zusammenzuführen.

Arten der Zusammenführung in Git

Git unterstützt drei Merge-Arten, die jeweils für ihr eigenes Szenario konzipiert sind. Die Wahl des Merge-Typs beeinflusst die Commit-Historie, die Rücknahmefreundlichkeit und die Lesbarkeit des Logs.

Fast-Forward Merge

Fast-Forward tritt auf, wenn der Ziel-Branch seit der Erstellung des Quell-Branches keine neuen Commits erhalten hat. In diesem Fall verschiebt Git einfach den Zeiger des Ziel-Branches nach vorne zum letzten Commit des Quell-Branches. Die Historie bleibt linear, ohne Merge-Commit.

# Fast-Forward-Merge: develop hat sich seit Feature-Erstellung nicht geändert
git checkout develop
git merge feature/new-login

# Ergebnis: Der develop-Zeiger wurde an das Ende von feature verschoben
# Es wurde kein Merge-Commit erstellt

Fast-Forward ist praktisch für kurzlebige Branches, an denen ein Entwickler allein gearbeitet hat. Aber dieser Ansatz hat einen Nachteil: Die Information, dass der Branch existierte, geht verloren — alle Commits sehen so aus, als wären sie direkt in develop gemacht worden.

Three-Way Merge

Three-Way Merge wird ausgeführt, wenn beide Branches nach dem Abweichungspunkt neue Commits haben. Git erstellt einen separaten Merge-Commit mit zwei Eltern, der die Tatsache der Branch-Zusammenführung festhält. Dieser Ansatz wird für Feature-Branches in der Teamarbeit empfohlen.

# Erzwungener Three-Way-Merge mit --no-ff-Flag
git checkout develop
git merge --no-ff feature/new-login

# Ein Merge-Commit mit Standardnachricht wurde erstellt
# Sie können Ihre eigene Nachricht über -m festlegen
git merge --no-ff feature/new-login -m "Merge feature/new-login into develop"

Das --no-ff-Flag garantiert die Erstellung eines Merge-Commits, selbst wenn Fast-Forward möglich ist. Dies ist eine bewährte Methode zur Bewahrung von Branching-Informationen in einem Projekt.

Squash Merge

Squash Merge komprimiert alle Commits des Quell-Branches in einen und wendet ihn auf das Ziel an. Die Feature-Historie geht verloren — ein einzelner Commit mit allen Änderungen landet im Branch. Dies ist praktisch, wenn detaillierte Commits in einem Feature-Branch keinen Mehrwert für die Gesamthistorie bieten.

# Squash-Merge: Alle Feature-Commits wurden in einen komprimiert
git checkout develop
git merge --squash feature/experimental
git commit -m "feat: experimental login flow (squashed)"

Squash eignet sich für Entwürfe, experimentelle Branches und Situationen, in denen es wichtig ist, eine saubere Historie zu bewahren. Der Nachteil ist, dass die Verbindung zu den ursprünglichen Commits verloren geht, was das Rückgängigmachen einzelner Änderungen erschwert.

Ours- und Theirs-Strategien

Ours und Theirs sind zwei spezielle Merge-Strategien in Git. Ours ignoriert Änderungen aus dem Quell-Branch vollständig und behält nur das, was im Ziel ist. Theirs akzeptiert dagegen bei jedem Konflikt die Version des Quell-Branches. Diese Strategien sind nützlich beim Zusammenführen großer Codemengen, wenn im Voraus bekannt ist, welche Version Vorrang haben soll.

Wie Merge funktioniert

Der Merge-Mechanismus in Git basiert auf dem Vergleich von drei Punkten: dem gemeinsamen Vorfahren (Merge-Basis), dem Zustand des Quell-Branches und dem Zustand des Ziel-Branches. Git findet die Merge-Basis — den letzten Commit, der beiden Branches gemeinsam ist — und berechnet, welche Änderungen in jedem Branch nach der Abweichung aufgetreten sind.

• Schritt 1 — Git bestimmt die Merge-Basis: den letzten Commit, der in beiden Branches vorhanden ist
• Schritt 2 — Git erstellt zwei Diffs: von der Merge-Basis zur Quelle und von der Merge-Basis zum Ziel
• Schritt 3 — Git versucht, beide Änderungssätze auf die Merge-Basis anzuwenden
• Schritt 4 — Wenn die Änderungen nicht kollidieren — wird der Merge automatisch abgeschlossen
• Schritt 5 — Bei einem Konflikt — stoppt Git und fordert eine Lösung an

Git verwendet einen Drei-Wege-Merge-Algorithmus, der nicht nur die beiden verglichenen Dateiversionen berücksichtigt, sondern auch deren gemeinsamen Vorfahren. Dadurch kann Git automatisch Situationen lösen, in denen Änderungen in einem Branch die modifizierten Bereiche des anderen nicht beeinträchtigen — selbst wenn beide Dateien modifiziert wurden.

Beispiel für die Merge-Funktionsweise

Betrachten wir ein Szenario: Zwei Entwickler arbeiten an verschiedenen Dateien in einem Feature-Branch. Der erste änderte LoginActivity.kt, der zweite änderte ProfileFragment.kt. Wenn sie ihre Änderungen zusammenführen, sieht Git, dass die Änderungen verschiedene Dateien betrafen, und führt den Merge automatisch ohne menschliches Eingreifen durch.

Wenn beide Entwickler LoginActivity.kt geändert haben, aber in verschiedenen Methoden — wird Git auch damit automatisch umgehen und die Änderungen zeilenweise zusammenführen. Ein Konflikt entsteht nur, wenn beide dieselben Zeilen geändert haben oder wenn einer Code gelöscht hat, den der andere geändert hat.

Konfliktlösung bei Merge

Ein Merge-Konflikt tritt auf, wenn Git Änderungen nicht automatisch zusammenführen kann, weil beide Branches dieselben Zeilen unterschiedlich modifiziert haben. In diesem Fall markiert Git die Konfliktbereiche in den Dateien und wartet auf die manuelle Lösung durch den Entwickler.

Konfliktbereiche werden mit speziellen Markierungen gekennzeichnet: <<<<<<< HEAD zeigt Code aus dem Ziel-Branch, ======= ist der Trenner, >>>>>>> source-branch zeigt Code aus dem Quell-Branch. Der Entwickler muss manuell auswählen, welche Version behalten oder ob sie kombiniert werden sollen.

# 1. Merge ausführen und Konflikt sehen
git merge feature/new-login
# Ausgabe: CONFLICT (content): Merge conflict in LoginActivity.kt

# 2. Liste der Dateien mit Konflikten anzeigen
git status
# both modified: src/ui/login/LoginActivity.kt

# 3. Konflikt lösen: Datei bearbeiten, Markierungen entfernen
# 4. Gelöste Datei hinzufügen und Merge abschließen
git add src/ui/login/LoginActivity.kt
git merge --continue
# oder: git commit (ohne --continue)

Es gibt Werkzeuge zur Konfliktlösung: git mergetool öffnet einen visuelle Merge-Anwendung (Meld, Beyond Compare, VS Code). Viele Entwickler lösen Konflikte lieber in der IDE — IntelliJ IDEA und Android Studio bieten ein integriertes Tool mit Drei-Fenster-Vergleich, das diesen Prozess erheblich vereinfacht.

Tipps zur Konfliktlösung: Verstehen Sie immer, was jede Konfliktseite tut, löschen Sie nicht den Code anderer, ohne seine Logik zu verstehen, und wenn der Konflikt zu komplex ist — beziehen Sie die Autoren beider Branches in eine gemeinsame Lösung ein.

Merge vs Rebase: Wann was wählen

Die Wahl zwischen Merge und Rebase ist eine der häufigsten Architekturentscheidungen in Git. Beide Ansätze kombinieren Änderungen, tun dies jedoch unterschiedlich: Merge bewahrt die Branching-Historie, Rebase schreibt die Historie um und macht sie linear.

• Merge — bewahrt den Kontext: Man kann sehen, wann und von welchem Branch eine Zusammenführung erfolgte. Besser für öffentliche Branches (develop, main) und Teamarbeit
• Rebase — erstellt eine saubere lineare Historie ohne zusätzliche Merge-Commits. Besser für persönliche Feature-Branches vor der Überprüfung
• Regel: Führen Sie niemals Rebase auf öffentlichen Branches durch, die andere Entwickler verwenden

Viele Teams verwenden einen hybriden Ansatz: Rebase, um den Feature-Branch mit develop zu aktualisieren (git rebase develop), und dann Merge mit dem --no-ff-Flag, um die Zusammenführung zu protokollieren. Dies ergibt eine saubere Historie innerhalb des Features und informative Zusammenführungspunkte auf develop-Ebene.