The choice between git rebase and git merge is argued about far more than it is understood on most teams. Both combine the work of two branches; the difference lies in how the history looks afterwards and in how you handle conflicts. This article walks through what each command actually does, when to reach for which, and the classic accidents teams run into, all with concrete examples.
Both do the same job, but write history differently
Say you branched feature off main, and while you were working, main moved on. Now you want the new commits from main in your branch. There are two ways to do this.
Merge takes the tips of both branches and creates a new merge commit. It leaves your commits untouched and simply ties the two histories together at a single point:
git checkout feature
git merge mainRebase instead sets your commits aside temporarily, moves the starting point of your branch to the latest main, and reapplies your commits one by one on top of that new base:
git checkout feature
git rebase mainThe result: after a merge the history branches and joins, while after a rebase the history looks like a straight line, as if you had been working on top of the current main all along.
Rebase copies commits, it doesn't move them
Here is the critical thing to understand: rebase doesn't move your commits, it copies them. Every reapplied commit gets a new hash, because even though its content is identical, it now hangs off a different parent. The old commits linger in your reflog for a while, but your branch now points at the new copies.
The practical consequence is big: rebase rewrites history. On a local branch you haven't shared with anyone, that is completely safe. But if you do it on a shared branch that others have pulled, everyone's history stops matching yours. That leads us to the single most important rule.
The golden rule: never rebase shared history
If you remember just one rule, you'll avoid most of the trouble:
- Freely rebase branches that are yours alone, not yet pushed, or that nobody has based work on.
- Never rebase branches everyone shares, like
mainordevelop.
If you rebased a feature branch that you had already pushed, you'll need to force-push to update the remote. Here, instead of a bare --force, always prefer the safer variant:
git push --force-with-lease--force-with-lease refuses the push if the remote branch differs from what you last saw (meaning someone else pushed in the meantime), so you don't silently clobber a teammate's work. A plain --force gives you no such protection.
Conflicts: all at once, or step by step
Conflict handling differs significantly between the two. With merge, all changes meet at a single point; you resolve the conflicts once, run git add, and complete the merge.
With rebase, because your commits are reapplied in sequence, conflicts can surface at each commit separately. If several of your commits touch the same line, you may have to resolve a similar conflict more than once. The flow goes like this:
# fix the conflicting files, then:
git add <file>
git rebase --continue
# to skip that commit:
git rebase --skip
# to cancel everything and go back:
git rebase --abortIf things get messy, git rebase --abort returns you exactly to the state before the rebase, so when you get stuck you can calmly cancel and try again rather than panic.
Cleaning up history with interactive rebase
Rebase's most powerful use isn't combining branches but editing your own commit history. With git rebase -i (interactive), you can squash, reorder, or fix the messages of commits before you push:
git rebase -i HEAD~4In the editor that opens, you pick a command for each commit: pick (keep as is), squash (fold into the previous one), reword (change the message), drop (delete). That lets you collapse a mess of "fix", "fix again", "typo" commits into one meaningful commit and make the pull request worth reviewing. Again, only do this on commits you haven't shared yet.
A practical team strategy
For most teams there's a hybrid approach that works well:
- To keep your feature branch current, rebase
maininto your branch (git rebase main) so the history stays flat and no useless merge commits pile up. - When bringing the feature branch into
main, use merge, often with--no-ff, so that "this feature landed here" stays clearly recorded in a single merge commit. - Before opening the pull request, tidy your commits with
git rebase -i.
Many teams also integrate PRs with "squash and merge": the whole feature lands on main as a single commit. That keeps the main history extremely readable, with each line corresponding to one feature. Whichever strategy you pick, what matters is being consistent as a team; a team where half rebase and half merge ends up with the worst history of all.
Frequently Asked Questions
Is rebase more dangerous than merge?
It isn't dangerous, it just has rules because it rewrites history. On local, unshared branches, rebase is completely safe and keeps the history clean. The only real danger is rebasing and force-pushing a shared branch others are using; as long as you don't break that rule, you can use it freely.
How do I cancel a rebase if a conflict appears?
The command git rebase --abort returns you exactly to the state before you started the rebase. You don't lose any commits, and bailing out to continue with a merge instead is a perfectly valid choice when you get confused.
What if I accidentally break my history?
git reflog is your safety net. Git keeps every old position your branch has pointed to for a while; find the right hash in the reflog and return to that moment with git reset --hard <hash>. That's why "rewriting history" is far less permanent than it sounds.
Want to simplify your team's Git workflow? Let's set up sensible branching strategies, CI/CD integration, and a clean commit history together. Get in touch and we'll design a workflow that fits your project.