When to use git rebase instead of git merge

Use rebase to reorganize commits you can safely rewrite. Use merge to combine histories while preserving their existing commit identities. Neither choice eliminates the need to resolve conflicts and test the combined behavior.

Where rebase helps

On a private feature branch, rebasing onto the current main branch can make its changes easier to review:

git fetch origin
git switch feature-x
git rebase origin/main

Interactive rebase lets you reorder, edit, or squash a selected series of commits:

git rebase -i origin/main

Check the selected base and todo list carefully. To transplant a series to another base, use git rebase --onto NEW_BASE OLD_BASE feature-x after identifying exactly which commits fall in that range. The operation replays commits and normally changes their IDs.

If replay pauses, resolve the affected files, stage the resolutions, and use git rebase --continue. Use git rebase --abort to cancel. Preserve unfinished work before starting.

Where merge fits better

Merge is usually the straightforward choice for shared branches whose commits other people already use. It preserves the original topology. A non-fast-forward merge creates an integration commit; a fast-forward simply advances the branch pointer.

Use git merge --no-ff feature-x when your workflow specifically wants a merge boundary even if fast-forwarding is possible. For long-lived parallel branches, merges avoid repeatedly rewriting the same published commits. They can still encounter conflicts on later integrations; there is no guarantee that a conflict needs resolving only once.

Treat published history as shared state

Avoid rebasing commits that others may have based work on unless the team has agreed on the rewrite and recovery process. A private branch is not automatically disposable just because only one person pushes to it.

A rebase of unpublished local commits onto the remote tip can be pushed normally. Rewriting already published commits may require a permitted force-with-lease push and coordination.

Common questions

Should pull use rebase?

Follow the repository's policy. git pull --rebase replays local work after fetching; git pull --no-rebase merges. git pull --ff-only refuses divergence. Configuration can change the behavior of a bare pull.

Is linear history always easier to debug?

It can be easier to scan, but git bisect also works on merge histories. Reverting a feature depends on how it was integrated: a squash commit, several individual commits, and a merge commit have different recovery semantics.

Can the two approaches be combined?

Yes. A common workflow cleans up a private branch with rebase, then integrates it through the team's chosen merge or squash process. Keep the distinction between private cleanup and rewriting shared history explicit.

References: git rebase, git merge, and git pull.