Rebase vs Merge
Summary
This note explains the difference between rebase and merge in Git. The goal is to understand how each one changes history, when each is useful, and why using the wrong one can make collaboration harder.
Why this matters
- many Git problems come from using the right command with the wrong mental model
mergeandrebasecan both combine work, but they tell the story of history differently- understanding the trade-off makes branch workflows easier to explain and safer to use
Environment / Scope
| Item | Value |
|---|---|
| Topic | Git history integration |
| Best use for this note | deciding whether to combine work with merge or rebase |
| Main focus | history shape, collaboration impact, safe use |
| Safe to practise? | yes, in a test repo |
Core idea
Think about the two commands like this:
merge
-> keeps branch history as it happened
-> adds a merge commit when histories join
rebase
-> rewrites commits as if they started from a newer base
-> creates a cleaner linear story, but changes commit historyMental model
| Command | What it does to history | Main effect |
|---|---|---|
merge | combines histories without rewriting existing commits | preserves branch shape |
rebase | replays commits onto a new base | rewrites local history into a cleaner line |
Everyday examples
| Situation | Better choice |
|---|---|
| you want to preserve the real branch history of teamwork | merge |
you want your local feature branch to sit cleanly on top of updated main before opening a PR | rebase |
| the branch is already shared and others may rely on the same commits | merge is usually safer |
| the branch is still local and messy | rebase is often fine |
Common misunderstandings
| Misunderstanding | Better explanation |
|---|---|
| ”Rebase is just a cleaner merge” | it also rewrites commit history |
| ”Merge means the history is messy” | it may be more honest about how work actually happened |
| ”Rebase is always better” | it is stronger only when cleaner linear history is worth the rewrite risk |
| ”If it works locally, rebasing shared commits is harmless” | rewritten history can confuse collaborators and remote branches |
Example history shape
With merge:
main: A---B-------E
\ /
feature: C---D---With rebase:
main: A---B
feature: C'--D'Then the branch can be merged forward with a simpler linear history.
Practical rule of thumb
Use:
mergewhen the branch is shared or when preserving the real shape of work mattersrebasewhen cleaning up your own local branch before integration
Be careful with:
- rebasing commits that are already shared with other people
- force-pushing rewritten history without understanding the impact
Decision test
Before choosing, ask:
- is this branch only mine, or already shared?
- do I need an honest branch history or a cleaner linear history?
- will rewriting these commits confuse anyone else?
- am I trying to clean up before a merge, or combine already-shared work?
Key takeaways
mergepreserves history shaperebaserewrites history into a cleaner line- the safest choice depends on whether the branch is local, shared, or already published