Git: merge branch into master, or master into branch

Question

I wonder if I'm making a mistake by first merging master into another branch, and then merging it back into master.

Suppose I create the following branches, each with a separate commit:

            mkdir git_merging             cd git_merging/             git init             touch on_master             git add .             git commit -m "Initial commit on master"              git checkout -b x             touch on_branch_x             git add .             git commit -m "Initial commit on branch x"              git checkout master             touch on_master_again             git add .             git commit -m "Commit on master after branching" 

Now I want to merge. Usually, I prefer to first merge master into x, and then to merge x into master:

            git checkout x             git merge -m "Merge master into x" master              echo "test results"             git checkout master              git merge x 

That way I can test things before merging back into master, ensuring that I always have a functioning master branch. As far as I can tell, there are no functional differences, compared to merging x directly into master:

            git merge -m "Merge x into master" x             git checkout x              git merge master  

In practice, I often encounter repositories that seem to exclusively merge back into master however. Are there any drawbacks to my approach? Any reasons why I shouldn't be doing this?

Answer 1

This is a pretty subjective question, but I will give it a pass because I think I can come up with a fairly objective answer.

It's a great practice to merge master back into your branch before merging it. What if someone else had committed something that broke the feature you just implemented (as you pointed out)? Or what if someone modified the same code you did, and caused possible merge conflicts? I actually suggest merging master back into your branch very frequently. This not only prevents you from having to spend a day and a half resolving merge conflicts (though, that may be a sign that your branches are too large, but that's another story), but it also keeps you in line as the project changes and evolves.

Some may say that you should rebase your commits on top of master. My short version is: I encourage people to open pull requests very early in the development process, even if a feature isn't done. This means you're likely pushing your code to a remote server (such as GitHub). In order to rebase your commits, you would have to push with a rewritten git history, and force push. Force pushing is a poor workflow decision and should be avoided, as it can cause (almost) permanent damage to your commit history.

So yes, merge back from master right before you are looking merge, and as often as you can otherwise. If you use GitHub, I even encourage using the new Protected Branches feature to enforce updating branches with master before merging: