There is a feature-branch x, it has a commit on file A. And then a Pull Request is created.
Then master has a new update, on file B, C, D.
So feature branch has 1 commit behind master. But as feature and master work on different files, there will be no merge-conflict.
For such case, i usually merge master into feature branch, before i merge the PR.
The question is, is it a MUST-DO, to sync master to feature branch, before the PR is merged, if feature and master work on different files? AND WHAT IS THE BEST-PRACTICE?
And WITHOUT sync master to feature branch, after PR is merged, on master, A file should be changed as the commit from feature branch, and fild B, C, D will not be overwritten by feature branch and stay the same as they are on master?
In Bitbucket, by clicking the button Merge in bitbucket-GUI, there are 3 Options:
Please see this document of bitbucket, in bicbucket GUI, for that case, the 3rd Option "fast-forward" is not possible: https://community.atlassian.com/t5/Bitbucket-questions/What-happens-if-I-merge-a-PR-that-is-out-of-sync-from-master/qaq-p/1291041
But what about i just use the other button "merge commit" or "squash"? Will it still work?
Thank you.
There is no technical constraint in git that prevents you from doing what you are suggesting. However, even if there is no conflict when merging, the edits in file B, C, D might not be compatible with your edits in A. git won't care if this is the case, but I guess you care that the merge does not lead to code in master not working properly. So you might not want to do what you are suggesting but not due to anything in how git works.
Here are some best practices you can consider:
rebase x on master - This will bring the edits in B, C, D to branch x. Do this if the edits in those file are relevant for how want to implement edits in file A. After rebasing, test your code in branch x and if no issues, then merge to master. This is the most common approach but could introduce an error on x.
new version branch - Create a new branch of master and merge x into the new branch. Test your code in the new branch as it will have all edits in A, B, C and D in it. If the code works, then merge the new branch to master. This requires most work as you create a new branch and do multiple merges, but makes sure that the error is never on either x or master. Probably overkill for a small edit.
merge directly - If you are sure there is no way edits to A can lead to errors when combined with the edits in B, C and D then you can merge directly.
The files in B, C and D will not be overwritten when merging x to master even though the x has the original version of those files. Think of it like this; branch x keeps track of edits done in that branch. When merging x to another branch only the those edits are merged. Since no edits are done in branch x to B, C and D, nothing will happen to those files in the branch x is merged to.