When should I use git rebase instead of git merge?

Both commands integrate work from one branch into another, and they differ in what happens to history. Merge records that two lines of development came together, creating a merge commit with two parents and leaving the original commits untouched. Rebase instead replays your commits on top of the target branch one at a time, producing new commits with new hashes and a single linear sequence.

The deciding rule is about who else has the commits. Rebasing rewrites history, so anyone who already pulled the original commits now has a divergent copy, and reconciling that is genuinely unpleasant. Rebase freely on branches only you have, and avoid it on shared branches unless the whole team has agreed and knows how to recover.

Within that rule, the common productive pattern is to rebase your own feature branch onto the updated main branch before opening a pull request. The result reads as though you started from current main, the reviewer sees only your changes rather than unrelated merge noise, and bisecting later is more straightforward because history is a straight line.

Conflict handling differs in a way that catches people out. A merge presents all conflicts once, in a single resolution step. A rebase replays commits individually, so the same conflicting region can surface repeatedly, once per commit that touches it. For a long-lived branch with many small commits, this can mean resolving essentially the same conflict several times, and a merge is often less painful.

Neither approach is technically superior. Merge preserves an accurate record of what actually happened, which some teams value for auditing. Rebase produces history that is easier to read after the fact. Most teams pick one convention and apply it consistently, because mixing them arbitrarily produces the drawbacks of both.