Git Merge führt zwei Entwicklungslinien in einem Git-Repository zusammen. Dabei werden die Änderungen eines Branches (z. B. feature/login) in den aktuell ausgecheckten Branch (z. B. main) integriert. Merge verändert die bestehende Historie nicht, sondern ergänzt sie — das unterscheidet es vom Rebase.
Fast-Forward und Three-Way-Merge
Hat sich der Ziel-Branch seit dem Abzweigen nicht bewegt, macht Git einen Fast-Forward: Der Zeiger von main wird einfach auf die Spitze des Feature-Branches vorgeschoben — die Historie bleibt linear. Sind beide Branches weitergezogen, braucht Git einen Three-Way-Merge mit dem gemeinsamen Vorfahren (Base) als dritter Vergleichsbasis:
git switch main
git merge feature/login
git merge --no-ff feature/login # erzwingt Merge-Commit, Historie bleibt nachvollziehbarMerge-Konflikte lösen
Haben beide Branches dieselbe Stelle unterschiedlich verändert, kann Git nicht automatisch entscheiden. Die betroffenen Dateien enthalten dann Konfliktmarker:
<<<<<<< HEAD
hallo von main
=======
hallo vom Feature-Branch
>>>>>>> feature/loginDie Marker werden manuell aufgelöst, danach git add und git commit (oder git merge --continue). Konflikte sind normal — sie lassen sich durch kleine Commits, häufiges Integrieren und git pull --rebase im Team reduzieren.
Merge-Strategien im Team
- Merge-Commit: bewahrt die echte Historie mit allen Nebenlinien; gut nachvollziehbar, aber unübersichtlicher.
- Squash-Merge: fasst alle Commits eines Branches zu einem zusammen; saubere lineare Historie.
- Rebase vor dem Merge: erzeugt eine perfekt lineare Historie (siehe Git Rebase).
Die Wahl hängt vom Team ab: Wer lineare, leicht lesbare Geschichten schätzt, nutzt Rebase + Squash; wer dokumentieren will, was wirklich passiert ist, setzt auf Merge-Commits.
Verwandte Grundlagen: Git Branch, Versionierung, git-Befehle.