Hello @Lynnard Mondigo ,
Do you mean some clashing changes in the PR source branch and in the target branch? You'll see conflicts for those files in that case, Bitbucket won't let you merge that PR until you resolve them.
Let me know if I got you wrong.
Not clashing per se. Let's say for example a PR that has been created few days ago has changes in File A but do not conflict with the current master. However, the PR is 10 commits behind (changes to Files B, C, D).
The question is, when I merge the PR, is the PR fastforwarded in the background? Will only the File A on master branch be affected?
Fast-forward will not work in this case, e.g. if you select fast-forwar only, PR merge will fail. This is because fast-forward is only possible when target branch has not changed since common merge base (since you branched off it).
You can merge the PR you described using a merge commit. Only file A will be updated on the master branch, just like it was on the PR source branch. So, in the end changes to all files A, B, C and D will appear in master.
Note that master could've had changes to file A too, but you'll be able to merge a PR only if such changes don't clash with the changes in that PR, e.g. if they're in different chunks of the file. Also, as described in this nice blog post, what Bitbucket shows you in PR UI is the future result of merging. So you will see potential changes to the same files done in the target branch on context lines.
Does this make sense?
Squash merge will squash all changes done in the source branch (as in, all changes from the tip of the source branch up to the merge base – latest common commit for source and destination branches) into one commit and put it on top of the destination branch. There will be no "merge commit" and no relation to the source branch if you didn't specify to close it.
Does this make sense? Here's the Git documentation on the merge --squash operation.
Unfortunately, this is not something I can suggest on, it is subject of controversy :)
This should be a personal preference or a convention within the team that works on the repository. Each option has its pros and cons, and there're debates on which one to use in which kind of projects.
For instance, if you want the repository history to be streamlined but are ok with losing some historical metadata, you'd prefer to squash or rebase + fast-forward. Likewise, if tracking how and when the code evolved, how different streams of worked co-existed, etc. is a must, you'd prefer to keep all commits like they are and hence use merge commits. However, the graph of the commits might become way more complicated in this case.
Hope this helps.
Hi everyone, We are looking to learn more about development teams’ workflows and pain points, especially around DevOps, integrations, administration, scale, security, and the related challeng...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events