Rebase or merge? Which one should I use
When to use this: You have seen both words and are not sure which to use to bring in new commits.
Before you start
Steps
-
Merge: keep history as it happened
terminalgit merge mainAdds one merge commit. Existing commits are untouched, so it is always safe to push afterwards.
-
Rebase: replay my commits on top of main
terminalgit rebase mainTakes your branch's commits, moves the branch tip to
main, and re-applies your commits one by one. Result: a straight line, but every commit gets a new ID. -
Give up on a rebase that went wrong
terminalgit rebase --abortReturns the branch to exactly how it was before you started.
-
After a rebase of an already-pushed branch
terminalgit push --force-with-leasePushed history changed, so a normal push is rejected.
--force-with-leaseoverwrites only if nobody else pushed to it since you last fetched. Only for your own branches, nevermain.
How to verify it worked
git log --oneline --graphshows the history shape you wanted.
How to undo it
Rebased and regret it? The old state is still in the reflog:
git reflog
git reset --hard "HEAD@{N}"Common errors and fixes
git add, git rebase --continue. If it is a mess, git rebase --abort and use merge. Q&A
One-line rule for rebase vs merge?
Rebase your own local, unpushed work to tidy it. Merge when other people (or Vercel previews, PRs) already depend on the branch.
Why is force-pushing dangerous?
It replaces the remote history. Teammates' commits can be erased and their clones break. --force-with-lease reduces, but does not remove, the risk.