-1

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:

  1. Merge Commit
  2. Squash
  3. Fast forward

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.

Zi Sang
  • 69
  • 1
  • 9
  • 1
    Can't you rebase the feature branch onto the master branch? Because that would solve the problem. – Kristof Neirynck Jun 21 '22 at 08:54
  • @KristofNeirynck Thank you, but the question is, if it a MUST-DO, if feature and master work on different file? If I NOT rebase the feature branch onto the master branch, or NOT merge master to the feature branch, will the merge of PR still work, and the file B, C, D stays same as master? – Zi Sang Jun 21 '22 at 08:58

2 Answers2

1

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.

TheIceBear
  • 2,912
  • 9
  • 23
  • Thank you very much for the reply! It is good to know for the option "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. " – Zi Sang Jun 21 '22 at 09:32
-1

Thank you very much to @TheIceBear! For my use-case, "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.

And now my summary: There are different ways to do it for my use cases.

There are 3 Options:

1. rebase feature onto master (see also answer from TheIceBear) It is the most clear way for git histroy. Command: #First fetch the new master from the upstream repository, then rebase your feature branch on top of that:

(Updates origin/master)

git fetch origin

(Rebases current branch onto origin/master)

git rebase origin/master

2. merge master into feature

a merge from the upstream branch into the feature branch leads to an not "nice" history, since another merge object is then always created

Command:

git checkout master

git pull

git checkout feature/x

git pull

git merge master

git push

3. merge directly

In bitbucket, Merge with "fast-forward" Merge will not work, but Merge with "squash" and "merge commit" will work, 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.

If feature and master work on different files, which means no conflicts, you can also consider not do the rebase. The result after the merge would of course be the same.

But then you would have "crossing" branch lines in the history, which isn't particularly nice either.

in summary: it is NOT a MUST-DO, but the feature branch is better always be from the current status of master to which it is then also merged

Zi Sang
  • 69
  • 1
  • 9