3

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

  1. 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.

  2. 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?

Emile Bergeron
  • 17,074
  • 5
  • 83
  • 129
kilgoretrout
  • 3,547
  • 5
  • 31
  • 46

1 Answers1

4

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.

Emile Bergeron
  • 17,074
  • 5
  • 83
  • 129
JB Nizet
  • 678,734
  • 91
  • 1,224
  • 1,255
  • 1
    Hi, thank you for you help! It makes sense for keeping linear history but if the `feature` branch is short-lived (i.e., will be deleted after merging), is it correct to simply merge `feature` INTO `master`, resolve conflicts that arise, and then delete feature? – kilgoretrout Nov 12 '16 at 05:29
  • The problem with this answer is that github does all it's merging with the `--no-ff` option, so you get a much messier tree. – Leon Aves Jun 25 '18 at 10:50