Git rebase and Mercurial rebase solve the same core problem—rewriting commit history to create a cleaner, linear path. But the workflows, commands, and edge cases differ in ways that can trip up even the most seasoned engineer.
In Git, a rebase is straightforward:
git checkout feature
git rebase main
Git takes commits from your branch, rewinds them, fast-forwards main, and replays your commits on top. Conflicts are resolved as they appear in the replay process. The result is a clean history without merge commits.
Mercurial rebase is an extension you must enable:
hg rebase -s feature -d main
Here, -s is the source changeset, and -d is the destination. Mercurial rebases changesets by moving them to a new parent, preserving logical order. Unlike Git, Mercurial tracks changesets as immutable objects, so rebase effectively creates new changesets while obsoleting the originals.
Both systems rewrite history, so local-only branches are safe, but shared branches require caution. In Git, history rewriting is destructive for public branches. In Mercurial, obsolescence markers can help, but you must ensure your team’s tooling supports them.
Key differences to remember:
- Git’s rebase integrates directly into its core commands; Mercurial needs the rebase extension enabled.
- Git replays commits; Mercurial moves changesets.
- Mercurial’s history model can retain metadata about rebased changes, aiding traceability.
- Command syntax is not interchangeable.
Choosing between Git rebase and Mercurial rebase comes down to the VCS you’re locked into. But if you juggle both, keep mental maps of their differences. Avoid muscle memory mistakes—git rebase and hg rebase may sound the same, but they carry different operational semantics.
Want to cut the friction from your branching and merging workflows? Try it live with hoop.dev and see a fully optimized setup running in minutes.