Git Rebase vs Merge

Also Known As

TL;DR

Explanation

git merge creates a merge commit that joins two branch histories — history is preserved exactly. git rebase replays feature branch commits on top of the target, rewriting SHAs — produces a clean linear history but changes commit identity. Interactive rebase (git rebase -i) allows squashing, reordering, and editing commits. Golden rule: never rebase commits that have been pushed to a shared branch — others' history diverges. Rebase is preferred for local cleanup; merge is safer for shared branches.

Common Misconception

Why It Matters

Common Mistakes

• Rebasing a branch others are working on — forces force-push and history divergence.
• Using git pull --rebase without understanding that it replays local commits on the remote — can cause conflicts.
• Squashing too aggressively — losing useful incremental commits that explain why a change was made.

Avoid When

• Never rebase commits that have already been pushed to a shared branch — it rewrites history others depend on.
• Avoid force-pushing to main or develop — it overwrites work and breaks others' local copies.

When To Use

• Use rebase to clean up local feature branch commits before opening a pull request.
• Use merge to integrate a completed feature into a shared branch — preserves context.

Code Examples

# Rebasing a shared branch others are using
git checkout main
git rebase origin/develop  # rewrites main — force-push required
git push --force origin main  # breaks everyone else's local main

# Local feature branch cleanup before PR
git checkout feature/my-feature
git rebase -i main  # squash WIP commits, clean up messages
git push origin feature/my-feature  # first push — safe to rebase

# Merging into main (preserves feature branch context)
git checkout main
git merge --no-ff feature/my-feature  # explicit merge commit

References

• ↗ https://www.atlassian.com/git/tutorials/merging-vs-rebasing

Tags

Related Terms