要約

When checking the PR diff on the Bitbucket Datacenter UI, the user can see differences in a file from 2 different branches, even though the changes are already present in the target branch.

環境

Bitbucket Datacenter 7.x Onwards

診断

This git behaviour can be reproduced following the below steps as an example:

• Create R1 branch
• Create branch release1 from master branch
• Create branch release2 from master branch
• Add changes to release1
• Mergerelease1 -> master
• Merge release1 -> R1
• At this point, there is no diff shown between R1 and the master
• Next, we add changes to release2
• Merge release2 -> master
• Merge release2 -> R1
• When we merge release2 to master and R1, the common ancestor shifts to the release2 commit which does not have the release1 changes. Hence the three-dot diff between R1 and master now shows changes from release1.
• This is also shown in the local git client (at git level)

% git diff master...R1                                                         
warning: master...R1: multiple merge bases, using 1e0e11602539baeb18ca0dc4f7fbb3dbbfeae26c
diff --git a/release1.txt b/release1.txt
new file mode 100644
index 0000000..594ae2a
--- /dev/null
+++ b/release1.txt
@@ -0,0 +1 @@
+release1

原因

• Since we took multiple parallel release branches at the same time which got merged back to R1 and master, the common ancestors would keep on changing resulting in unexpected diffs between R1 and master.
• The above behaviour stems from how diffs are shown in pull requests. Since Bitbucket 7.x the pull request will show the commits that exist between the common ancestor of the two branches and the tip of the source branch. If you run "git diff <tip of target branch>...<tip of source branch>" and if you get the same result that shows up in the pull request UI, then it is not an issue as Bitbucket is essentially showing what Git is doing.  Here's the visual representation:

ソリューション

• Make sure that your developers are aware of the change and adjust the internal processes/workflow accordingly. Some helpful documents to follow: Gitflow workflow
• The document does provide an example of release branches however it only mentions the creation of one release branch at a time after which all feature development stops. (Below is an excerpt from the document)

  Once develop has acquired enough features for a release (or a predetermined release date is approaching), you fork a release branch off of develop. Creating this branch starts the next release cycle, so no new features can be added after this point—only bug fixes, documentation generation, and other release-oriented tasks should go in this branch.

  Note that the document only offers a broad overview of the Git workflow, however, designing a specific workflow for your team is beyond the scope of Atlassian Support Offerings.