Merge — was es ist, wie merge funktioniert und Zusammenführungsstrategien

Was ist merge in Git

Merge ist der git merge-Befehl, der Änderungen aus dem angegebenen Branch in den aktuellen Branch zusammenführt. Git findet den gemeinsamen Vorfahren (Basis-Commit), berechnet den Diff jedes Branches relativ zum Vorfahren und erstellt einen Merge-Commit mit der kombinierten Änderungsmenge. Das Ergebnis ist, dass der Ziel-Branch alle Änderungen aus dem gemergten Branch erhält.

Syntax: während du dich im Ziel-Branch (z. B. main) befindest, führe git merge feature aus. Git erstellt automatisch einen Merge-Commit, wenn keine Konflikte vorliegen. Die Standard-Merge-Commit-Nachricht lautet: „Merge branch 'feature' into main“. Du kannst die Nachricht mit dem Flag -m ändern oder im geöffneten Editor bearbeiten.

Merge ist eine nicht-destruktive Operation. Anders als rebase berührt merge vorhandene Commits nicht: sie behalten dieselben Hashes, Autoren und Daten. Dies macht merge zur einzig sicheren Methode, Branches zusammenzuführen, an denen mehrere Entwickler gleichzeitig arbeiten. Wenn etwas schiefgeht, kann merge mit git merge --abort abgebrochen werden.

# Zum Ziel-Branch wechseln
git checkout main

# Feature-Branch mergen
git merge feature

# Ergebnis — Merge-Commit mit zwei Eltern
git log --oneline --graph

# Merge mit benutzerdefinierter Nachricht
git merge feature -m "feat: integrate authentication module"

Merge-Typen: regular, squash, fast-forward

Git unterstützt drei Zusammenführungsmodi, die je nach gewünschtem Ergebnis gewählt werden. Der reguläre Merge (Standard) erstellt einen Merge-Commit. Squash-Merge fasst alle Commits des Feature-Branches in einem zusammen. Fast-forward verschiebt den Branch-Zeiger, ohne einen Commit zu erstellen, wenn möglich. Die Wahl des Modus hängt vom Workflow des Teams und den History-Regeln ab.

Regulärer Merge (--no-ff) — erstellt einen Merge-Commit, selbst wenn der Merge als Fast-forward durchgeführt werden könnte. Für den main-Branch empfohlen: ein Merge-Commit markiert eindeutig den Integrationspunkt des Features und ermöglicht es, alle Änderungen des Feature-Branches mit einem einzigen Revert des Merge-Commits rückgängig zu machen. GitHub verwendet diesen Modus standardmäßig beim Zusammenführen von PRs über den Merge-Button.

Squash-Merge (--squash) — sammelt alle Commits des Feature-Branches in einem einzigen Commit im Ziel-Branch. Nützlich, wenn die Entwurfshistorie des Feature-Branches main nicht verschmutzen soll. Nachteil: die Verbindung zu den ursprünglichen Commits geht verloren — man kann nicht sehen, wie das Feature Schritt für Schritt entwickelt wurde. GitHub verwendet diesen Modus bei Auswahl von „Squash and merge“ in einem PR.

Fast-forward (--ff) — wenn der Ziel-Branch seit der Abzweigung des Feature-Branches keine neuen Commits hat, verschiebt Git einfach den Zeiger nach vorne, ohne einen Merge-Commit zu erstellen. Die Historie bleibt linear. Das Flag --no-ff erzwingt einen Merge-Commit, während --ff-only einen Fehler ausgibt, wenn Fast-forward nicht möglich ist.

# Merge-Commit erzwingen (für main empfohlen)
git merge --no-ff feature

# Squash-Merge — alle Commits in einem
git merge --squash feature
git commit -m "feat: add authentication"

# Fast-forward nur wenn möglich
git merge --ff-only feature

# Konfliktreichen Merge abbrechen
git merge --abort

Git-Zusammenführungsstrategien

Zusammenführungsstrategien bestimmen den Algorithmus, den Git zum Zusammenführen von Änderungen verwendet. Jede Strategie eignet sich für verschiedene Szenarien. Git wählt automatisch die passende Strategie, aber Entwickler können sie explizit mit dem Flag --strategy angeben. Das Verständnis der Strategien hilft, das Verhalten von Git bei komplexen Merges vorherzusagen.

Recursive — die Standardstrategie zum Zusammenführen von zwei Branches. Git findet den gemeinsamen Vorfahren, berechnet die Änderungen in jedem Branch und führt sie zusammen. Wenn ein gemeinsamer Vorfahr gefunden wird, behandelt recursive Dateiumbenennungen und -hinzufügungen korrekt. Bei Konflikten kann recursive zusätzliche Optionen verwenden: ours (automatisch unsere Version wählen) und theirs (deren Version wählen).

Octopus — zum gleichzeitigen Zusammenführen von mehr als zwei Branches: git merge feature1 feature2 feature3. Octopus unterstützt keine Konfliktlösung — alle Konflikte müssen vor dem Aufruf des Befehls gelöst werden. Es wird selten verwendet, hauptsächlich zum Zusammenführen mehrerer unabhängiger Branches, die garantiert nicht kollidieren (z. B. verschiedene Module).

Ours — eine spezielle Strategie, die Änderungen aus dem gemergten Branch vollständig ignoriert und den aktuellen Inhalt des Ziel-Branches beibehält. Ein Merge-Commit wird erstellt, aber der Inhalt bleibt unverändert. Nützlich, wenn du in der History den Merge-Vorgang festhalten, aber tatsächlich alle Änderungen aus dem anderen Branch ablehnen möchtest.

Merge-Konflikte lösen

Ein Merge-Konflikt tritt auf, wenn dieselben Zeilen einer Datei in beiden Branches unterschiedlich geändert wurden. Git kann nicht automatisch bestimmen, welche Version korrekt ist, und pausiert den Merge. Ein Konflikt kann auch entstehen, wenn eine Datei in einem Branch umbenannt und in einem anderen geändert wird, oder wenn dieselbe Datei gleichzeitig gelöscht und geändert wird.

Lösungsprozess: Git markiert konfliktbehaftete Dateien mit Markierungen. Die Datei zeigt Abschnitte mit <<<<<<< HEAD (unsere Version), ======= (Trennzeichen) und >>>>>>> feature (deren Version). Der Entwickler bearbeitet den konfliktbehafteten Abschnitt manuell, wählt die gewünschten Zeilen aus beiden Versionen aus, entfernt die Markierungen, speichert die Datei und fügt sie mit git add zum Index hinzu.

Für die visuelle Konfliktlösung unterstützt Git mergetool — ein externes Vergleichswerkzeug. Beliebte Mergetools: Meld, KDiff3, Beyond Compare, VS Code (integrierter Konflikt-Editor). Mergetool zeigt drei Fenster an: unsere Version, deren Version und das Ergebnis. Der Entwickler wählt visuell Codeblöcke für die Aufnahme in die endgültige Datei aus.

# Merge starten und Konflikt erkennen
git merge feature
# KONFLIKT (Inhalt): Merge-Konflikt in src/main.swift

# Konfliktdateien prüfen
git status

# Visuelles Mergetool öffnen
git mergetool

# Nach Lösung — add und commit
git add src/main.swift
git commit

# Merge abbrechen
git merge --abort

Wann merge statt rebase wählen

Merge ist rebase vorzuziehen in mehreren Schlüsselsituationen. Erstens: bei der Arbeit mit öffentlichen Branches, die für andere Entwickler zugänglich sind. Merge überschreibt die Historie nicht, sodass Kollegen sicher synchronisieren können. Rebase in einem öffentlichen Branch erzeugt eine abweichende Historie und verursacht Konflikte bei allen, die bereits die alten Commits haben.

Zweite Situation: beim Abschließen eines Feature-Branches. Die meisten Teams bevorzugen merge (mit dem Flag --no-ff) in main, um den Integrationszeitpunkt des Features festzuhalten. Dies vereinfacht die Navigation in der Historie und ermöglicht es, ein ganzes Feature mit einem einzigen git revert des Merge-Commits rückgängig zu machen. GitHub Flow bietet standardmäßig drei Merge-Optionen: einfachen Merge, Squash-Merge und Rebase-Merge.

Dritte Situation: bei der Arbeit mit einem überprüften Pull-Request. GitHub und GitLab bieten einen Merge-Button mit verschiedenen Optionen. Merge (Create a merge commit) — vollständige Historie mit einem Merge-Commit. Squash and merge — saubere Historie ohne Entwicklungsdetails. Rebase and merge — lineare Historie ohne Merge-Commit, aber mit Umschreibung von Commits. Die Wahl hängt von den Teamregeln ab.

• Öffentliche Branches (main, develop) — nur merge, niemals rebase.
• PR-Abschluss — merge mit --no-ff zur Markierung des Integrationspunkts.
• Branches mit fremden Commits — merge überschreibt fremde Arbeit nicht.
• Vor dem Release — merge ist sicherer, da es weniger Risiken birgt.
• Gemeinsamer Branch — wenn mehrere Entwickler an einem Branch arbeiten, ist merge Pflicht.

Bewährte Praktiken für Branch-Zusammenführung

Erste Regel: vor dem Merge stets auf der aktuellsten Version des Ziel-Branches sein. Führe git checkout main && git pull aus, bevor du den Feature-Branch mergst. Dies minimiert Konflikte und stellt sicher, dass der Merge-Commit alle aktuellen Änderungen enthält. Wenn der Ziel-Branch deutlich voraus ist, führe zuerst git merge main innerhalb des Feature-Branches aus, um Konflikte in dessen Kontext zu lösen.

Zweite Regel: Code nach dem Merge testen. Merge kann das Verhalten ändern, selbst wenn es keine Konflikte gab. Die CI/CD-Pipeline sollte Tests auf dem Merge-Commit ausführen, bevor sie in die Produktion sendet. Einige Teams verwenden Merge-Gates — obligatorische Prüfungen, die den Merge blockieren, bis sie bestanden sind.

Dritte Regel: Merge-Commits dokumentieren. Die Standardnachricht „Merge branch 'feature' into main“ ist wenig nützlich. Es wird empfohlen, eine Beschreibung dessen hinzuzufügen, was gemergt wurde: „Merge authentication module: login, registration, password recovery“. Dies vereinfacht die Historienanalyse und die Suche nach Regressionen. In großen Projekten werden Merge-Commits automatisch aus dem PR-Titel generiert.

• Aktualität — vor dem Merge sicherstellen, dass der Ziel-Branch aktuell ist (git pull).
• Tests — CI/CD sollte Tests auf dem resultierenden Merge-Commit ausführen.
• Aussagekräftige Nachrichten — im Merge-Commit angeben, welches Feature gemergt wurde.
• Häufigkeit — Feature-Branches so früh und oft wie möglich mergen (maximal eine Woche).
• Rückgängigmachen — git revert eines Merge-Commits macht das gesamte Feature rückgängig.