All comparisonsGit

git merge vs git rebase

Both bring changes from one branch into another, but they do it differently. git merge creates a new merge commit that ties two histories together, so nothing is rewritten. git rebase replays your commits one by one on top of the target branch, producing a linear history, but it changes commit hashes, which is dangerous on anything already shared with others.

Left

git merge

Right

git rebase

History shapePreserves branching, adds a merge commitLinear, no merge commits
Commit hashesUnchangedRewritten for every replayed commit
Safety on shared branchesSafe to run anytimeUnsafe after others have pulled the branch
Conflict resolutionResolve once, in the merge commitMay need to resolve the same conflict per commit
Typical useMerging a finished feature into mainCleaning up a feature branch before opening a PR

Use git merge when

You are integrating a completed, shared, or public branch and want an honest record of when it happened.

Use git rebase when

You are tidying up your own local feature branch before pushing, and want a clean, linear commit history for review.

The verdict

Rebase your own unpublished work to keep history readable. Merge once a branch is public or shared, so you never rewrite commits someone else already has.

Study this on the roadmap

Git & Version Control