I am confused on the proper way to manually merge a pull request, and to understand why there are different suggestions regarding it.
Suppose the simplest situation: one master
(long-lived) branch and one single feature
branch with several commits for which a pull request is made but which shows merge conflicts with the master branch.
GitHub says to do:
git fetch origin
git checkout -b feature origin/feature
git merge master
and then
git checkout master
git merge --no-ff feature
git push origin master
Why do we merge master
into feature
and then the reverse after that? This SO suggests the order doesn't matter but This SO suggests there are issues relating to the parent.
This SO discusses manually merging pull requests but says you only need to merge your master branch into your feature branch and that's it. How is that consistent with what GitHub says?
For your point 2, it doesn't say to merge the story into master because that's not what the OP wants to do.
Regarding your question. Let's assume we have this:
master
*---*----*----*
\
---*----*
feature
If you merge master into feature, that will bring all the changes made into master to your feature branch. The feature branch will contain the latest changes from master plus the changes in the feature:
master
*---*----*----*
\ \
---*----*--*
feature
master will thus still point to the same commit as before, but feature will point to a new commit, which has all the changes for both branches.
So you still need to merge back the changes from the feature to master. That's a very simple operation now, since master is an ancestor of feature. So merging is a simple fast-forward:
*---*----*----*
\ \
---*----*--*
feature
master
I much prefer keeping a linear history, and thus rebasing the feature branch on master before merging it into master. But your mileage may vary.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With