Pull request showing changes from target branch not present in source branch

[Daniel Longest]

My team follows a feature branching workflow where each team member creates a feature branch from master, works on changes locally, then submits a pull request against master.  We've noticed that if changes are made to master after the feature branch has been created, then the pull request will include both commits from the feature branch (that only exist there) plus commits that have landed on master since the last time master was pulled.  

My primary question:  is this the way Bit Bucket is designed to work?  If so, that seems strange to us (we would expect the PR to only show commits on the feature branch that aren't in master) so my secondary questions:  is there a way to get the behavior I'm describing or is there a change we need to our individual workflows (such as always pulling master before opening the PR) to achieve the desired effect?

Daniel

[Daniil Penkin · Accepted solution]

Hello @Daniel Longest,

Thanks for reaching out.

Yes, this is the way Bitbucket was designed to work. The main idea is such diff would clearly show merge conflicts AND potentially surface logical conflicts that merge cleanly. There's a very nice blog post explaining the details of this approach.

However note that the highlighted changes in the pull request are always introduced by the feature branch (unless it's a conflict – the changes were made on both sides then).

Hope this makes sense. Let me know if you have any questions.

Cheers,
Daniil