Missing code changes after PR merge in Bitbucket Data Center

Summary

Expected code changes are missing from the target branch after merging the pull request.

Example scenario

1. A user encounters conflicts when attempting to merge the develop branch into the master branch through a pull request (PR1). Both branches are protected, preventing them from locally resolving the conflicts in any of them.

2. To avoid this, the user creates a new branch, conflict-resolve, removes it from the master branch, and merges the develop branch to resolve conflicts.

3. During the conflict-resolution process in the branch conflict-resolve, the user unintentionally unstages non-conflicted files, intending to fix the conflicts solely.

4. After resolving conflicts and staging only the conflicted files, the user commits these changes and submits a new pull request (PR2) from conflict-resolve to master.

5. Upon merging PR2, PR1 is automatically marked as merged. However, the changes from the non-conflicted files that were not staged and committed are lost in the master.

Environment

• Tested on Bitbucket Data Center 7.21.x

• Applies to Bitbucket Data Center 7.x and 8.x

Diagnosis

• PR1 is automatically marked as merged even though it shows files having conflicts.

• This merge is triggered by another pull request (PR2) created to resolve the conflicts.

• Even though PR1 (feature → master) is marked as merged, some of the feature code is not visible in the master branch.

Cause

Example case study

• A user initiates a pull request (PR1) to merge changes from the develop branch into the master branch, but encounters a conflict in one of the files.

  

• To resolve this conflict, the typical approach is to check out the develop branch locally and merge the master branch. The user would then resolve the conflicts, commit the changes, and push them back to the remote develop branch.

• However, the source branch (and the target) might be protected, preventing local merges without a pull request.

• In this case, the user creates a new branch from the master named conflict-resolve and merges the develop branch into this new branch specifically to resolve conflicts.

  % git checkout conflict-resolve % git pull origin develop From ssh://Bitbucket-URL:7999/nproj/repo1 * branch develop -> FETCH_HEAD Auto-merging file2.txt CONFLICT (content): Merge conflict in file2.txt Automatic merge failed; fix conflicts and then commit the result.

• After resolving the conflicts in affected files in the branch conflict-resolve the user elevates only these affected files (file2.txt) to the index and unstages the non-conflicted files (file1.txt) to solely focus on fixing conflicts in this branch.

  % git status On branch conflict-resolve Your branch is up to date with 'origin/conflict-resolve'. All conflicts fixed but you are still merging. (use "git commit" to conclude merge) Changes to be committed: modified: file1.txt modified: file2.txt % git reset HEAD file1.txt Unstaged changes after reset: M file1.txt

• Next, the user completes the merge and pushes the branch to the remote.

  git merge --continue git push

• The user then creates a second pull request (PR2) to merge the conflict-resolve → master branch, incorporating the conflict resolution changes.

  

• Upon merging PR2, an unexpected event occurs: the initial pull request (PR1) is automatically marked as merged. However, changes in non-conflicted files, such as file1.txt, are omitted from the master branch.

  

• More importantly, the diff between the develop and master branches becomes empty, preventing users from bringing those left out changes into the master branch.

  

Explanation

Below is a visual representation of the git workflow in this case study.

• When the develop branch is merged into the conflict-resolve branch, all commits from develop are incorporated into conflict-resolve.

• As a result, merging conflict-resolve into master automatically marks the initial pull request (PR1: develop → master) as merged.

• It's crucial to note that any changes made during the conflict resolution process, such as unstaging parts of the develop code, will reflect the current state of the master branch.

• After the conflict-resolve branch is merged, the user can't re-merge the develop branch into master because there will be no differences between the two. This is because all commits from develop are already present in the master branch's history; hence, no more changes can be merged from the new common ancestor between the two.

Solution

If detected immediately, create a new branch and manually copy the code left out to this branch, and merge it again.