Wie funktioniert das Mergen in Git?

Question

Accepted Answer

**Mergen** kombiniert Änderungen von einem Branch in einen anderen — typischerweise wird ein abgeschlossener Feature-Branch zurück in den Haupt-Branch gebracht. Git führt die meisten Merges automatisch durch, aber das Verständnis von Merge-Typen und **Konflikten** ist wichtig. ## Basis-Merge ```bash git switch main # be on the branch you want to merge INTO git merge feature-x # merge feature-x's changes into main ``` Sie wechseln zum **Ziel-Branch** (derjenige, der Änderungen erhält) und mergen den **Quell-Branch** hinein. ## Fast-forward vs Merge-Commit ```text FAST-FORWARD merge → if main hasn't changed since the branch was created, Git just MOVES main's pointer forward to the branch's latest commit (no merge commit, linear) MERGE COMMIT (three-way merge) → if BOTH branches have new commits, Git creates a new "merge commit" combining them (has two parents) → preserves that a merge happened → git merge --no-ff forces a merge commit even when fast-forward is possible ``` Git macht einen Fast-forward, wenn möglich (einfaches Verschieben des Zeigers), oder erstellt einen **Merge-Commit** (mit zwei Parent-Commits), wenn beide Branches divergiert sind. ## Merge-Konflikte ```text A CONFLICT happens when both branches changed the SAME lines differently — Git can't auto-decide which to keep, so it asks YOU to resolve: ``` ```text <<<<<<< HEAD the version from the current branch (main) ======= the version from the branch being merged (feature-x) >>>>>>> feature-x ``` ```bash # resolve: edit the file to the desired result, remove the markers, then: git add # mark the conflict resolved git commit # complete the merge # git merge --abort # or cancel the merge entirely ``` **Konflikte** treten auf, wenn beide Branches die gleichen Zeilen ändern — Git markiert sie und Sie wählen manuell das korrekte Ergebnis, stagen es dann und committen es. ## Warum es wichtig ist Das Verständnis von Merging ist essentiell, weil das Kombinieren von Branch-Änderungen ein grundlegender, ständiger Teil von kollaborativen Git-Workflows ist, daher ist das Wissen, wie es funktioniert (inklusive Konflikte), notwendiges alltägliches Wissen. **Merging** ist der Weg, wie abgeschlossene Arbeit (typischerweise Feature-Branches) zurück in den Haupt-Branch integriert wird — die alltägliche Handlung des Zusammenführens von Änderungen, die ständig in der Team-Entwicklung passiert. Das Verständnis des Unterschieds zwischen einem **Fast-forward Merge** (Git verschiebt einfach den Zeiger, wenn der Ziel-Branch nicht divergiert ist, wodurch die Historie linear bleibt) und einem **Merge-Commit** (ein Drei-Wege-Merge, der einen neuen Commit mit zwei Parent-Commits erstellt, wenn beide Branches neue Commits haben, und aufzeichnet, dass ein Merge stattgefunden hat) verdeutlicht, wie Git Änderungen integriert und wie die resultierende Historie aussieht. Am wichtigsten ist das Verständnis von **Merge-Konflikten** — die auftreten, wenn beide Branches die gleichen Zeilen unterschiedlich ändern, sodass Git nicht automatisch entscheiden kann und Sie bittet zu lösen — ist entscheidend praktisches Wissen: Konflikte sind ein normaler, unvermeidbarer Teil der Kollaboration, und zu wissen, wie man die Konflikt-Marker (`<<<<<<<`, `=======`, `>>>>>>>`), erkennt, die Datei zum korrekten Ergebnis bearbeitet und den Merge abschließt (stagen und committen), ist eine essenzielle Fähigkeit, die oft eine Quelle von Angst für diejenigen ist, die sie nicht verstehen. Da das Integrieren von Branch-Änderungen durch Merging grundlegend und ständig in kollaborativer Entwicklung ist, und da das Verständnis von Merge-Typen und besonders das Auflösen von Konflikten notwendig ist, um Arbeit korrekt zu kombinieren (eine alltägliche, unvermeidbare Aufgabe), ist das Verständnis, wie Merging funktioniert — Basis-Merges, Fast-forward vs Merge-Commits und Konfliktauflösung — essentielles, häufig angewendetes Git-Wissen, eine Kernfähigkeit für die Kollaboration, wobei die Konfliktauflösung insbesondere eine praktische Notwendigkeit ist, die jeder Entwickler selbstbewusst bewältigen muss.