Why does git merge-base and git rev-parse return the same hash for a reverted branch?

[Nitin Choudhary]

I’m seeing different behavior between Bitbucket and GitHub when working with revert branches in plain Git.

After creating a branch to revert another branch and pushing it to Bitbucket, I fetch the latest and run:

git fetch origin
git merge-base HEAD origin/revert-branch
git rev-parse origin/revert-branch

On Bitbucket, both commands return the same commit hash as if the reverted branch tip is the merge base itself.

But on GitHub, the same setup returns different hashes, where merge-base points to the correct ancestor commit (as expected).

git log locally shows full history for the revert branch, so the branch clearly diverges, but merge-base treats it as linear only on Bitbucket.

This happens only for revert branches, for regular feature branches, both platforms behave identically.

Is Bitbucket internally fast-forwarding or rewriting revert branches on the remote side, or is there some other difference in how Bitbucket handles revert commits or branch refs that causes this?

I’d like to understand whether this is expected Bitbucket behavior or an artifact of how revert branches are recorded or merged.

[Syahrul]

Hey @Nitin Choudhary 

Welcome to the community!

The only possible reason this happens is likely that you push a revert branch that is a direct descendant of the branch you reverted. No new commits have been added to the target branch; the merge-base will be the tip of the revert branch (since it's the only ancestor).

However, without actually looking into your test, it's hard to determine whether this is the case. If you would like to investigate it further, feel free to raise a support ticket on our Support portal with your test and evidence repository.

Regards,
Syahrul