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.
