Pull request shows commits which are already present in target branch.

[Deepak S]

Hello,

I'm trying to find out why my feature branch pull request to master branch shows commits which are already part of master. I was hoping to see only changes that I made in feature branch that are new to master branch. 

This is what I have done so far

1. Created a feature branch based off of a released tag (older than latest released tag).

2. Merged latest released tag changes to this feature branch. 

3. Made some new changes

4. Created a pull request from this feature branch to master. 

Changes that got merged from the latest released tag (step 2) are showing up in my pull request along with new changes I made. Please not that changes from released tag are already present in master branch as we always release our code from master branch. 

I'm not sure if I'm doing something wrong here or if there is another way to make sure my pull request will show only changes which are new to target branch. 

Thank you in advance! 

[Caroline R]

Hi, @Deepak S! Welcome to the community! 

Could you please confirm if this problem is occurring on Bitbucket server or Bitbucket Cloud? 

Thank you! 

Kind regards,
Caroline

[Deepak S]

Hello Caroline, Thank you for the response! It is happening on Bitbucket Cloud. 

[Caroline R]

Hi, @Deepak S! 

I tried to reproduce this scenario, but I couldn’t see the behavior you see, so I assume you are doing something different than I did. In this case, I will need some additional details to further investigate this issue.

• For step 1: does the tag you are creating the new branch from belong to master?

• For step 2: are you merging a certain tag that belongs also to master in that new feature branch?
  Which merge strategy do you use?

• It would also be helpful if you could give an example of commit graph (using letters instead of commit hashes), e.g. like (where A, B, C are commits): 

A - B (tag 1.0) - C - D - E (tag 2.0) - F [master branch]
      \
       G [feature branch]
and explain what they do, the exact commands you use, and what you see using that example commit graph. This will help me understand what you’re doing, try to reproduce, and see if it’s expected or not.

Thank you!

Kind regards,
Caroline

[Marek Kon]

Hi,

I do not know if this is the case with @Deepak S , but I have a problem with PR commits that appear despite the fact that they are already present on the target branch. The situation is shown in the picture below. After updating branch B (M-> B) and creating a PR from B to D, all commits from branch A reappear in that PR.

[Vishal Deshmukh]

Hi Marek,

I am facing similar issue.

My first question is during M->B merge, was it a simple merge or did it shown changes in files which were not modified in B ?

Second Question : Is merging MASTER into Feature branches is a good practice ?

[Marek Kon]

Hi,

re 1. if during the development of a feature on the B branch, changes appeared on the M branch, then such a merge took place, because there were changes on M that were not in B (even sometimes there may be conflicts),

re 2. if the feature branch is created from Master and then merge from Master to is not done, then on pull request to Master, conflicts may arise, which bitbucket itself can not handle and you will have to resolve such conflicts manually locally. So this is not only a good practice, but also a necessity.

[Vishal Deshmukh]

Isn't rebase a standard practice instead of merging master into feature ?

What are the pros/cons of both workflows ?