Git Merge vs Rebase
Preserve history vs rewrite it
Merge and rebase are both ways to integrate changes from one Git branch into another, but they produce different commit histories and have different implications for collaboration.
Merge
Git merge creates a new 'merge commit' that combines two branches, preserving the complete history of both. The branch topology is visible — you can see exactly when branches diverged and converged. It's non-destructive: no existing commits are changed. This is the default and safest integration strategy.
Rebase
Git rebase replays your branch's commits on top of another branch, creating new commits with new hashes. The result is a linear history — as if you wrote all your changes after the latest main branch commit. It rewrites history, which means commit hashes change. This produces cleaner logs but alters the commit graph.
Key Differences
- **History**: Merge preserves true history. Rebase creates a linear, cleaned-up history. - **Merge commits**: Merge creates them. Rebase avoids them. - **Safety**: Merge never rewrites history. Rebase rewrites commits (dangerous for shared branches). - **Conflicts**: Both can cause conflicts, but rebase resolves them commit-by-commit. - **Golden rule**: Never rebase commits that have been pushed to a shared branch. - **Readability**: Merge shows the messy truth. Rebase tells a cleaner story.
When to Use Each
**Use merge** for integrating shared branches (main/develop), when you want to preserve the full history, or when multiple people have worked on the branch. **Use rebase** for keeping feature branches up to date with main (before merging), cleaning up local commits before sharing, or when your team prefers linear history.
Analogy
**Merge** is like stapling two documents together with a cover page noting they were combined — both originals are intact and you can see the seam. **Rebase** is like retyping your document so it looks like you wrote it after the other person finished — cleaner result, but the original drafts are gone.