Git Merge vs Git Rebase — What's the Difference and When to Use Which

You've been working on a feature branch. Meanwhile, main has moved ahead. Now you need to bring those changes together. You have two options: merge or rebase. Most developers pick one without really understanding the other. This article will change that.

Table of Contents

1. The Situation — Setting the Stage

2. Git Merge — Keeping History as It Happened

3. Git Rebase — Rewriting History for a Clean Line

4. Merge vs Rebase — Side by Side

5. When to Use Merge

6. When to Use Rebase

7. The Golden Rule of Rebase

8. Summary and Conclusion

1. The Situation — Setting the Stage

Let's say your repository looks like this:

main:    A --- B --- C
                \
feature:         D --- E

You branched off main at commit B to work on a new feature. While you were working, your teammates pushed new commits to main — so main is now at C, but your feature branch only knows about A and B.

Now you want to bring the feature branch into main. You have two ways to do this:

• git merge

• git rebase

Both accomplish the goal — but they tell very different stories in your commit history.

2. Git Merge — Keeping History as It Happened

What it does

git merge takes the two branch histories and joins them together, creating a brand new commit called a merge commit. It keeps the full record of everything — when branches diverged, when they came back together, and who did what.

Think of it as: "Keep everything as it happened. Just join the branches."

How it looks

Before merge:

main:    C1(ABC) --- C2(AB'C) --- C3(AB'C')
                \
feature:         F1(A'BC) --- F2(A'BCD)

After git merge main (from the feature branch):

main:    C1 --- C2 --- C3 -----
                \               \
feature:         F1 --- F2 ----- NC (Merge Commit)
                                 (A'B'C'D)

Git creates a new merge commit (NC) that has two parents — the tip of main (C3) and the tip of feature (F2). This merge commit contains all the changes from both branches combined.

Commands

# Step 1: Make sure you're on the feature branch
git checkout feature

# Step 2: Merge main INTO feature
git merge main

# This creates the merge commit (NC) automatically

What git log looks like after merge

NC   ← merge commit (A'B'C'D0)
C3
F2
F1
C2
C1

The log shows the full branching history — you can see exactly when and where things diverged.

Key characteristics of git merge

• ✅ Keeps original history — nothing is rewritten, everything is preserved exactly as it happened

• ✅ History is 100% honest — shows when branches were created and merged

• ✅ Safe for shared/public branches — you're never rewriting commits others may have based work on

• ✅ Shows when branches were merged — useful context for teams

• ⚠️ Creates a merge commit — adds an extra commit to the log

• ⚠️ Log can look non-linear — with many branches, history can look like a web of lines

3. Git Rebase — Rewriting History for a Clean Line

What it does

git rebase takes your feature branch commits and replays them on top of the latest main. Instead of creating a merge commit, it moves your commits so it looks like you started working from the latest version of main all along.

Think of it as: "Make it look like I started from the latest main."

How it looks

Before rebase:

main:    C1(ABC) --- C2(AB'C) --- C3(AB'C')
                \
feature:         F1(A'BC) --- F2(A'BCD)

After git rebase main (from the feature branch):

main:    C1 --- C2 --- C3
                            \
feature (rebased):           F1'(A'B'C') --- F2'(A'B'C'D)

Your feature commits (F1, F2) are replayed on top of C3, creating brand new commits (F1', F2'). The original F1 and F2 are gone — replaced by their rewritten versions. The history now looks perfectly linear, as if you had branched off C3 from the start.

Commands

# Step 1: Make sure you're on the feature branch
git checkout feature

# Step 2: Rebase onto main
git rebase main

# Git will replay your commits one by one on top of main

What git log looks like after rebase (on main)

F2'  ← new commit (A'B'C'D)
F1'  ← new commit (A'B'C')
C3
C2
C1

Clean, linear, no merge commit. It reads like a straight line from start to finish.

Key characteristics of git rebase

• ✅ History is linear and clean — easy to read and navigate

• ✅ No merge commit — log stays uncluttered

• ✅ Looks like you started from the latest main — great before opening a Pull Request

• ⚠️ Rewrites history — commits get new SHA hashes (F1 → F1', F2 → F2')

• ⚠️ Risky if misused on shared branches — rewriting commits others are using causes serious problems

• ⚠️ Loses the "when did branches diverge" information — history is cleaned up, not preserved

4. Merge vs Rebase — Side by Side

5. When to Use Merge

Use git merge when:

• Integrating a completed feature into main — this is the standard way to merge a Pull Request

• Working in a team on shared branches — merge is safe because it doesn't rewrite any existing commits

• You want to preserve the full history — stakeholders or reviewers need to see when and where things happened

• You're merging long-running branches — branches with a lot of history are safer to merge than rebase

# Standard team workflow — merge feature into main
git checkout main
git merge feature

6. When to Use Rebase

Use git rebase when:

• Cleaning up your feature branch before opening a Pull Request — makes your commits easier to review

• Your branch has fallen behind main — rebase brings it up to date without a merge commit

• Working on a personal/local branch that hasn't been shared — safe to rewrite since no one else has based work on it

• You want a clean, readable git log — especially important for open source projects

# Clean up your feature branch before a PR
git checkout feature
git rebase main

# Then open your Pull Request

7. The Golden Rule of Rebase

⚠️ Never rebase a branch that other people are working on.

This is the most important rule in all of Git rebase.

Here's why it's dangerous: When you rebase, Git creates brand new commits with new SHA hashes to replace the old ones. If a teammate has already pulled your old commits and based new work on them, their history now conflicts with yours. When they try to push or pull, Git gets confused because it sees two different versions of what should be the "same" commits.

The result is a messy, painful conflict that's hard to untangle and can genuinely corrupt shared history.

Safe rule of thumb:

8. Summary and Conclusion

Here's the mental model to carry with you:

Use merge when you're integrating finished work. It's honest, safe, and shows the full story of your history.

Use rebase when you're cleaning up your own work before sharing it. It produces a cleaner, linear history that's easier for reviewers to follow.

They're not enemies — they're different tools for different moments in your workflow. A common pattern in professional teams looks like this:

# 1. While developing, keep your feature branch up to date via rebase
git checkout feature
git rebase main          # Stay current, clean history

# 2. When the feature is done and ready — merge via Pull Request
git checkout main
git merge feature        # Integrate the finished work safely

This gives you the best of both worlds: a clean feature branch that's easy to review, and a main branch that safely preserves the full integration history.

The one-line summary

Merge preserves history. Rebase rewrites it. Use merge to integrate. Use rebase to clean up. Never rebase shared branches.

Found this helpful? Share it with a developer who's been avoiding rebase out of fear — it's one of those things that clicks once and then you can't unsee it. 🚀