You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
We have been experiencing issues with our multi-branch workflow for some months now. We've never had this problem before. Even if the commits are already on the target branch, "merged" commits generated by pull requests appear as new file changes, complicating the review process. Our multi-branch workflow is (to reproduce the issue):
For each new feature or bug fix, we create a new named development branch from master (production) on our repository fork.
After we finish developing and testing, we submit a pull request, which is then merged into our staging branch (final test before production) for further testing.
We use the development branch (not staging) to make a pull request to master after testing is completed to avoid introducing additional untested fixes or changes from the staging branch. We merge this pull request into master.
There should be no changes when we create a new pull request from master to staging at this point, but the development to master pull request's auto generated "merged" commit is displayed alongside the previously merged commits on the pull request diff. Submitting the pull request causes the "normal" commits to vanish from the list, leaving only the "merged" commit. We confirmed that the changes depicted on the pull request diff are already in staging, and that the "Files changed" are identical to the "merged" commit(s) shown on the commit view.
Is anyone else having this issue? I saw a similar question, but there was no response to fix or acknowledge the problem.
We recently changed our diff algorithm from what we call a '3-way' diff to a 2-way 'three-dot' diff.
The '3-way' diff included changes to the destination branch, whereas the 'three-dot' diff does not reflect changes made to the destination branch since the source branch was created from the destination branch. The 'three-dot' diff will show the difference between the tip of a source branch and the commit from which it branched off the destination:
In order to see the changes to the target branch reflected in the diff, you can sync the target branch to your source branch. The sync can be done by merging the target branch into the source branch (locally or in the UI), or it can be done by rebasing the source branch locally. Instructions for both are detailed here.
We have experienced a scenario similar to the one described above, and have two follow-up questions.
1. What happens if the source branch was not created from the destination branch? In our case, we have multiple feature branches created from master, and a long-running qa branch, created from master some time ago. As we complete development for a specific feature is complete, the corresponding feature branch is being merged into qa. What we started seeing is bitbucket diff between feature and qa shows differences in files that are actually identical - can this be explained by the bitbucket diff change described above?
2. I tried to find an option for the git diff command that would perform the "3-way" diff, but it appears that one does not exist. Does that mean that before the change bit bucket was able to show "3-way" diff results by performing git merge without commit behind the scenes?
Appreciate any feedback!
Hi. We are having exact same issue, and almost same branching model. Only instead of development branch we are using bunch of feature branches like feature-1, feature-2 etc.
I'd like to ask @Theodora Boudale and community for better solution.
Can we see merge conflicts locally? Yes we can, but that makes usage of Bitbucket kind of less valuable. If not using it for team-collaboration online, then why use it anyways?
Can we merge the target branch into the source branch in UI? No we can't! That is the cornerstone of the issue.
We cannot merge staging branch into our feature branch, because then, if we merge feature branch into master (production) branch, then it will contain everything we are testing on staging right now, including features not ready for production.
And since we are fully into deployment automatization, any merge commit into master branch means instant automatic deployment.
If necessary, I can provide an example in the form of public repository with several branches.
Hi. The only "solution" we could come up for our specific issue was to sync the target branch (staging) with master before every pull request. You can do it by using the Sync action in Branches. To be honest, it's not great because it takes longer than it should to do a pull request. We only send one change to staging at a time, so we never have problems with conflicts because staging and the development branch should always be in sync with master. Only in rare cases do we have more than one update in staging, and that's usually because something else is broken and needs to be fixed before the other can go through testing