Rebase vs merge: what is the difference, and which would you use on a shared branch?

Both integrate changes from one branch into another, but they record history differently. Merge creates a new merge commit with two parents and leaves existing commits untouched, so history shows what really happened, including the branching. Rebase takes your commits and replays them one by one on top of another base, producing a clean linear history, but every replayed commit gets a new SHA: it rewrites history.

On a shared branch I would merge, or more precisely, never rebase commits that other people already have. Rebasing is great for tidying my own feature branch before it is reviewed or merged.

Picture it

Before:            A---B---C  main
                        \
                         D---E  feature

git merge main     A---B---C-------M  feature (M has parents E and C)
(on feature)            \         /
                         D-------E

git rebase main    A---B---C---D'---E'  feature (D', E' are new commits)
(on feature)

Why rebasing shared commits is dangerous

If a teammate has D and E and you rebase to D' and E' then force-push, their branch now diverges from yours with “duplicate” commits. Their next pull either creates confusing merges or reintroduces the old commits, and work can be lost if someone force-pushes over it. That is the “golden rule of rebasing”: do not rebase commits that exist outside your repository and that others may have built on.

A typical safe workflow

# on my own feature branch
git fetch origin
git rebase origin/main            # replay my work on latest main, resolve conflicts per commit
npx playwright test               # re-run tests: rebase can break things without conflicts
git push --force-with-lease       # safe-ish force push of MY branch

--force-with-lease refuses to overwrite the remote branch if it changed since you last fetched, which protects a colleague’s commits that you have not seen. Plain --force does not.

Before opening a PR, interactive rebase cleans up history:

git rebase -i origin/main   # squash "fix typo" commits, reword messages, reorder

How teams usually combine them

• Feature branches: rebase on main to stay current (private branches only).
• Integrating into main: through a pull request with merge, squash merge, or rebase-and-merge, chosen by the team and enforced by repository settings. Squash merge gives one commit per PR; merge commits preserve the branch structure.
• main / release branches: protected, no force pushes.

Trade-offs

	Merge	Rebase
History	true, non-linear	clean, linear
Rewrites commits	no	yes
Conflict resolution	once, in the merge commit	per replayed commit
Safe on shared branches	yes	no
git bisect friendliness	fine	very good (linear)

A linear history makes git log and git bisect easier; a merge history is more honest about how work happened. Neither is “correct”; consistency within the team matters more.

What interviewers look for

• Accurate mechanics: merge commit versus replayed commits with new SHAs.
• The golden rule and the reason behind it.
• --force-with-lease instead of --force.
• Practical team workflow: rebase private branches, merge or squash via PRs into protected branches.