What is the difference between git merge and git rebase?
Quick Answer
Merge combines two branches with a new merge commit, preserving the exact history of what happened. Rebase re-writes your branch's commits so they sit on top of the target branch, producing a linear history but changing commit hashes. Rule: rebase your local/private work, but never rebase commits others have already pulled.
Merge takes two branches and ties them together with a merge commit — the history shows exactly what happened, including the divergence. Rebase instead lifts my branch's commits off and replays them on top of the target branch, so the history comes out linear, but the commits get new hashes because they've effectively been rewritten. The golden rule is you only rebase commits that haven't left your machine — never rebase something other people have already pulled, or you force everyone to untangle it. My usual flow is rebase my feature branch onto main to keep it current and clean, then merge or squash-merge the pull request.
- Merge: honest, non-destructive, but history has “bubbles” and lots of merge commits.
- Rebase: clean, linear, easy to read/bisect — at the cost of rewriting history (new SHAs).
- Golden rule: don't rebase a branch that's shared/published — it forces everyone else into a painful re-sync.
- Common workflow: rebase your feature branch onto
mainbefore opening/merging the PR to keep history tidy, then merge (or squash-merge) the PR. git rebase -ialso lets you squash, reorder and reword commits.