Git Rebase vs. Merge: Die richtige Wahl

Merge und Rebase führen Branches zusammen – aber unterschiedlich. Lernen Sie, wann Sie welche Strategie verwenden sollten.

Der Unterschied

# Ausgangssituation
      A---B---C  feature
     /
D---E---F---G    main

# Nach MERGE
      A---B---C
     /         \
D---E---F---G---M    main (M = Merge-Commit)

# Nach REBASE
              A'--B'--C'  feature (neu geschrieben)
             /
D---E---F---G             main

Vergleich

Merge verwenden

# Feature-Branch in main mergen
git checkout main
git merge feature-branch

# Mit Merge-Commit erzwingen
git merge --no-ff feature-branch

# Fast-Forward wenn möglich
git merge --ff-only feature-branch

Wann Merge?

Rebase verwenden

# Feature-Branch auf main rebasen
git checkout feature-branch
git rebase main

# Interaktiver Rebase (Commits bearbeiten)
git rebase -i main
git rebase -i HEAD~3  # Letzte 3 Commits

# Nach Rebase in main mergen (fast-forward)
git checkout main
git merge feature-branch

Interaktiver Rebase

git rebase -i HEAD~4

# Editor öffnet sich:
pick abc1234 Add user model
pick def5678 Add user controller
pick ghi9012 Fix typo
pick jkl3456 Add tests

# Optionen:
# pick   = Commit verwenden
# reword = Commit verwenden, Message ändern
# edit   = Commit verwenden, aber stoppen zum Bearbeiten
# squash = Mit vorherigem Commit zusammenführen
# fixup  = Wie squash, aber Message verwerfen
# drop   = Commit löschen

# Beispiel: Commits zusammenführen
pick abc1234 Add user model
squash def5678 Add user controller
fixup ghi9012 Fix typo
pick jkl3456 Add tests

Wann Rebase?

Die goldene Regel

# ❌ NICHT machen:
git checkout main
git rebase feature  # main ist shared!

# ❌ NICHT machen:
git push origin feature
# ... später ...
git rebase main
git push --force origin feature  # Wenn andere daran arbeiten!

# ✅ OK:
git checkout my-local-feature
git rebase main
git push origin my-local-feature  # Erster Push, niemand hat es

Rebase + Force Push (sicher)

# Wenn nur Sie am Branch arbeiten:
git rebase main
git push --force-with-lease origin feature

# --force-with-lease ist sicherer als --force
# Schlägt fehl wenn jemand anders gepusht hat

Konflikte lösen

# Bei Merge-Konflikten
git merge feature
# CONFLICT in file.js
git status                    # Zeigt Konflikte
# Konflikte in Dateien lösen
git add file.js
git commit                    # Merge abschließen

# Bei Rebase-Konflikten
git rebase main
# CONFLICT in file.js
# Konflikte lösen
git add file.js
git rebase --continue         # Weiter mit nächstem Commit

# Oder abbrechen
git rebase --abort

Typischer Workflow

# 1. Feature-Branch erstellen
git checkout -b feature/new-login

# 2. Arbeiten, committen
git add .
git commit -m "Add login form"
git commit -m "Add validation"

# 3. Vor PR: main holen und rebasen
git fetch origin
git rebase origin/main

# 4. Optional: Commits aufräumen
git rebase -i origin/main

# 5. Pushen
git push origin feature/new-login

# 6. PR erstellen, Review, Merge (auf GitHub/GitLab)

Squash Merge (GitHub/GitLab)

# Alle Commits eines PRs werden zu einem:

# Feature-Branch:
abc123 Add login form
def456 Fix styling
ghi789 Add tests
jkl012 Fix review comments

# Nach Squash Merge in main:
xyz999 Add login feature (#123)

# Aktivieren in GitHub:
# Settings → Merge button → Allow squash merging

Weitere Informationen

• 🌿 Git Branching Strategien
• 📚 Git Grundlagen
• 🔄 GitHub Actions