PR Diff shows different content from the actual file content in Bitbucket Datacenter
Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Summary
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.
Environment
Bitbucket Datacenter 7.x Onwards
Diagnosis
This git behaviour can be reproduced following the below steps as an example:
Create
R1branchCreate branch
release1from master branchCreate branch
release2frommasterbranchAdd changes to
release1Mergerelease1->masterMerge
release1->R1At this point, there is no diff shown between
R1and themasterNext, we add changes to
release2Merge
release2->masterMerge
release2->R1When we merge
release2tomasterandR1, the common ancestor shifts to therelease2commit which does not have therelease1changes. Hence the three-dot diff betweenR1andmasternow shows changes fromrelease1.This is also shown in the local git client (at git level)
1
2
3
4
5
6
7
8
9
% 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 @@
+release1Cause
Since we took multiple parallel release branches at the same time which got merged back to
R1andmaster, the common ancestors would keep on changing resulting in unexpected diffs betweenR1andmaster.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:
Solution
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.
Was this helpful?