Git Rebase vs Merge: The Actual Difference and When Each One Is Right

Merge creates a merge commit that joins two branches. Rebase moves your commits onto the tip of another branch as if you'd started your branch from there. Same end result — your changes are integrated — but very different Git histories.

What merge looks like

You're on feature-branch. You run `git merge main`. Git finds the common ancestor, applies your changes on top of main's latest state, and creates a merge commit with two parents. The history is truthful: it shows that these changes were made in parallel and then merged at a specific point in time.

What rebase looks like

You're on feature-branch. You run `git rebase main`. Git takes each of your commits, temporarily removes them, updates your branch to the latest main, then replays your commits one by one on top. The result is a linear history. Your commits look like they were always made after main's latest changes.

The golden rule of rebase

Never rebase commits that have been pushed to a shared branch. Rebase rewrites commit hashes. If you rebase commits that teammates have based their work on, you've changed the history they're working with. They'll have conflicts that look impossible. Use rebase on local branches or branches only you're working on.

When to use merge

• Integrating a feature branch into main — the merge commit preserves context
• Collaborative branches where multiple people are pushing
• When you want to see exactly when and how branches were integrated
• When you're using a GitHub Pull Request flow (PRs are merge-based by default)

When to use rebase

• Updating your local feature branch with the latest main before opening a PR
• Cleaning up messy local commits with interactive rebase before pushing
• Keeping a linear history on projects where that's a team convention

Interactive rebase: the underused superpower

`git rebase -i HEAD~5` opens an editor showing your last 5 commits. You can squash several commits into one, edit commit messages, reorder commits, or drop commits entirely. This is how you turn a messy 'wip', 'fix', 'fix again', 'actually fix' commit history into clean, reviewable commits before opening a PR.