Merge vs Rebase - Decision Guide

Table of contents

1. The Dilemma
2. Merge Explained
3. Rebase Explained
4. Comparison Table
5. Decision Guide

1. The Dilemma

You are developing on a branch. Main has moved forward. How do you integrate?

    A---B---C main
   /
  D---E feature-branch

2 options:

• MERGE: Merge with a merge commit
• REBASE: "Move" your commits after main

Which one to choose? It depends on your goal!

Back to table of contents

2. Merge Explained

Command:

git checkout main
git merge feature-branch

Visual result:

    A---B---C-------M main
   /               /
  D---E-----------/  (M = merge commit)

What happens:

1. Git creates a new commit (M)
2. This commit combines the changes from both branches
3. The history shows that there were 2 lines of development

Benefits:

• ✅ Truthful history: You see that there were 2 parallel developments
• ✅ Simple: One command, one conflict resolution
• ✅ Safe: Never alters existing commits
• ✅ Standard: Default approach in most teams

Drawbacks:

• ❌ Complex history: Many merge commits
• ❌ Less readable: Hard to follow the linear evolution

Back to table of contents

3. Rebase Explained

Command:

git checkout feature-branch
git rebase main

Visual result:

    A---B---C---D'---E' main

What happens:

1. Git "detaches" your commits D and E
2. "Replays" them after commit C
3. Creates new commits D' and E' (same changes, new hashes)
4. The history becomes linear

Benefits:

• ✅ Clean history: Straight line, easy to read
• ✅ Fast-forward merge: No merge commit
• ✅ Story-like: As if you had developed after main

Drawbacks:

• ❌ Rewrites history: D and E become D' and E'
• ❌ More complex: Several conflict resolutions possible
• ❌ Dangerous: Never rebase shared commits!

Back to table of contents

4. Comparison Table

Back to table of contents

5. Decision Guide

Use MERGE when:

Situations:

• You are starting with Git
• You work in a team
• You want to keep the "true" history
• You want the safest solution
• You merge long-lived branches

Commands:

git checkout main
git pull origin main
git merge feature-branch
git push origin main

Use REBASE when:

Situations:

• You want a clean, linear history
• Your branch is short and personal
• You have not shared your commits yet
• Your team prefers a linear history
• You have a good command of Git

Commands:

git checkout feature-branch
git rebase main               # Resolve conflicts if needed
  git checkout main
git merge feature-branch      # Fast-forward merge
  git push origin main
  ```

### **GOLDEN RULE:**

**NEVER REBASE SHARED COMMITS!**

```bash
# DANGER - NEVER do this:
git push origin feature-branch    # Shared commits
git rebase main                   # Rewrites shared commits = TEAM CHAOS

# OK - Rebase only locally:
git rebase main                   # Commits still local = OK
git push origin feature-branch    # Push after rebase = OK

Recommendation by level:

Popular team strategies:

1. "Merge only": Simple, safe, complete history
2. "Rebase then merge": Local rebase + merge on main
3. "Squash merge": 1 commit per feature (GitHub style)

The important thing = consistency in the team, not technical perfection!

Back to table of contents