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
As in the title I explained. Target branch shows differences for already merged changes because of pull request commit id.
Here is merge strategies that we are following :
1. "feature" branch created made same developments
2. "feature" branch merged to "dev" branch by pull request.
3. same "feature" branch merged to "test" branch by pull request.
Until here everything is okay. "dev" and "test" are equal.
Then I decided to develope new feature.
4. I created new branch from "dev"" branch let's call it "feature-2"
5. I made my development and I merged it to "dev" branch by pull request.
6. same "feature-2" branch merged to "test" branch by pull request.
In the step-6, Bitbucket shows changes that are already merged in step-3
How can we solve this problem? As our business requirement we need to follow this branching and merging strategy but it is annoying to see in every commit previous merged changes.
I think this problem is appear because of the bitbucket creates auto commit id for each pull request but still it is not make sense to see previous merged changes in every pull request.
Hi, @Ali, welcome to the community!
I couldn't find any Bitbucket account linked to the email you used to create this community question, so could you please confirm if the problem is related to Bitbucket Cloud or Server?
If it is Cloud, I was unable to reproduce this behavior, so can you create a test public repo and reproduce this, then share with us: (1) the link of the Pull Request with the issue (2) which exactly are the changes that shouldn’t be there.
Please feel free to share any additional information regarding this case.
Hi @Caroline R,
At our company, we are experiencing the exact same problem for some months now. Our process is comparable to what @Ali described:
I'm too experiencing the same issues lately on BB Cloud.
Let's assume we have the following branches:
Now A is created from D. a PR is created for Feature A which is then merged onto T.
B is started from D but is dependant of A, so A is merged into B. 1 commit is then done afterwards and a new PR is created of B. All the Changes from A are now shown in the Diff of the PR as well whereas those changes are actually already on T.
This process has been used quite a while now but seems to give these issues as of lately regarding PR diffs. This is just a simple example of a real case but we're seeing more Diffs being added up with old commits actually already merged from AND to different branches. Some diffs were even showing around 40 - 50 lines of commits where 1 or 2 commits were actually applied making the PR system unusable.
It is as somehow the PR mechanics or merging strategy have been changed as of lately and i couldn't point out the issue yet.
the latest situation of the above case has been worked around creating the B branch of from A instead of branching of from D and merging A afterwards. This resulted in the exact same commit hashes with only the missing merge commit (obviously) so i have no clue why that helped.
Hi. I asked a new question about it, and I received an answer. To improve performance, Bitbucket switched from a "3-way" diff to a 2-way "three-dot" diff (see blog here). To remove these extra commits, you must first sync the target branch before submitting the pull request. It is extra work, but there is nothing else you can do