Merge vs. Rebase — Know Both, Use Deliberately

Two Ways to Combine Histories

Merge creates a new commit that ties two histories together. Nothing is rewritten — the full, literal history of both branches is preserved, including every intermediate "wip" commit.

git switch main
git merge feature-x     # creates a merge commit joining main + feature-x

Rebase replays your branch's commits one by one on top of another branch's latest commit, producing a clean, linear history — but it rewrites commit hashes, which is why it's dangerous on shared/pushed branches.

git switch feature-x
git rebase main          # replay feature-x's commits onto latest main

The One Rule That Prevents Every Rebase Disaster

Never rebase a branch other people have already pulled. Rebasing rewrites history; if someone else built on the old commits, their next pull turns into a conflict nightmare. Rebase your own local, not-yet-shared work. Merge (or squash-merge) everything else.

	Merge	Rebase
History	Preserves everything, non-linear	Linear, rewritten
Safe on shared branches	Yes	No
Best for	Combining finished work into main	Cleaning up your own branch before opening a PR