← Git

Branches

What is the difference between merge and rebase, and when should you use each one?

Show answer — try answering out loud first

Merge joins two branches by creating a merge commit; it preserves the real history exactly as it happened, but leaves a branched history. Rebase rewrites history by reapplying your commits on top of a new base; it leaves a clean, linear history, but changes the commit hashes. The golden rule: never rebase public history; use merge to integrate what is shared.

Both do the same thing (integrate changes), but the result in the history is different:

  • Merge

    • Creates a merge commit with two parents.
    • Preserves the exact history: you can see when and from where it branched.
    • A more "tangled" history but faithful to reality.
    • Safe on shared branches.
  • Rebase

    • Reapplies your commits on top of another branch, creating new commits.
    • Linear history, easy to read.
    • Rewrites history (new hashes).
    • Dangerous if the branch is already published.

When to use each:

  • Use rebase to clean up your own local branch before sharing it (bring it up to date with main, tidy up commits).
  • Use merge to integrate already-shared branches, especially when bringing a feature into main.

The golden rule: don't rebase commits you already pushed and that others might have. If it's already public, integrate it with merge.

# --- MERGE: integrate feature into main preserving the history ---
git switch main
git merge feature
# Creates a merge commit (if both branches advanced)
# History: stays branched, with the join point visible

# --- REBASE: bring feature up to date with main, linear history ---
git switch feature
git rebase main
# Reapplies feature's commits on top of main
# History: stays in a straight line, without a merge commit

# Common and safe flow:
# 1. local rebase to clean up/update your branch
git switch feature
git rebase main
# 2. merge to integrate into the shared branch
git switch main
git merge feature

Rebasing a shared branch and causing conflicts and confusion for your teammates, because the commits they had now have different hashes. The other extreme also exists: filling the history with unnecessary merge commits when a local rebase would have left everything cleaner. The key is public = merge, local = rebase if you want to clean up.

"Both integrate changes, but merge creates a merge commit and preserves the history exactly as it happened, leaving a branched history that's safe for shared branches. Rebase rewrites history by reapplying my commits on top of another base, leaving a clean, linear history, but with new hashes. I use rebase to clean up or update my local branch before sharing it, and merge to integrate what is already public. The golden rule is to never rebase history that others already have."

Quick challenge

A teammate already pulled your feature branch. You want to bring it up to date with main. Rebase or merge?

Show answer

Merge (either git merge main inside feature, or integrate via a PR). Since the branch is already public and another person has those commits, a rebase would rewrite the hashes and cause them divergent histories and hard conflicts. The golden rule says: don't rebase shared history. Rebase would have been valid only if the branch were solely yours and you hadn't shared it yet.