This guide explains how reverting a merged pull request works with Bitbucket Data Center.

Git revert creates new commits that undo earlier changes. Revert does not delete or change existing history - it adds one or more new commits in an attempt to return the codebase to how it was before the reverted changes. How a revert works depends on the merge strategy used when the pull request was merged, as each strategy records commits differently.

If newer changes have touched the reverted area, Git may not be able to apply the revert cleanly. In such cases, you may need to resolve conflicts and revert locally.

Currently only pull request merge strategies that result in a single commit are supported:

• Merge commit (--no-ff)

• Rebase and merge (rebase + merge --no-ff)

• Squash (--squash)

• Squash, fast-forward only (--squash --ff-only)

They can be split into two categories: merge commits and squash merges.

1. Reverting a Merge Commit

With a merge commit strategy, merging a pull request creates a single merge commit with two parents:

• The main branch (the target branch of the pull request)

• The head of the pull request branch.

When you revert a merge commit that brings changes A and B from the pull request branch, the main branch will no longer contain changes A and B:

Main branch:     o -- o ------ M -- R     < No longer sees A and B changes
                       \      /     
Pull request branch:    A -- B      

                  Merge commit M    Revert commit of M

Note: For simplicity, these diagrams show the revert applied directly to the main branch, though in practice, the revert often occurs on a intermediate branch via a new Pull Request.

If development continues on the pull request branch with changes C and D and is later merged into the main branch, changes A and B will not be reintroduced because they already exist in the history of the main branch:

Main branch:     o -- o ------ M -- R -- M2     < Still no A and B changes, 
                       \      /         /                     only C and D
Pull request branch:    A -- B -- C -- D     

                                         Second merge commit M2 

To bring changes A and B back there are two options:

• revert the revert commit, or

• cherry-pick or rebase A and B onto the pull request branch to get new commit hashes. These will appear as new changes and will merge normally.

2. Reverting a squash-merged pull request

With a squash merge, all commits from the pull request are combined into a single new commit on the target branch.

When you revert a squash merge, Git creates a single new revert commit that undoes the changes from that squashed commit. This process is straightforward because there is only one commit to invert.

The history will show both the squash commit and the revert commit, allowing you to see when the changes from the pull request were added and subsequently undone.

Main branch:  o -- o -- o -- S -- o -- R

         Squash merge commit S         Revert commit R