Does Bitbucket handle the fast-forward of branches or will my merge revert the files that are out of sync from master?
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.
Cheers,
Daniil
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?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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?
Cheers,
Daniil
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
It makes sense now and I've tried it out also using test repos.
You have mentioned using a merge commit. How about a squash commit? Will it have the same result aside from all commits in the PR being squashed into one?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Last question before I accept your answer.
For PRs that are usually commits behind develop (no merge conflicts), do you suggest merge commit or squash commit?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.