Git: merge a branch into a master or a master into a branch

Question

I wonder if I'm wrong, first merging the master into another branch, and then merging it with the master.

Suppose I create the following branches, each of which has 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 -bx 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 unite. I usually prefer to combine master into x first and then combine x to 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 check things out before merging back into the master, ensuring that I always have a valid 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 come across repositories that seem to be exclusively merged back into masters. Are there any flaws in my approach? Any reasons why I shouldn't do this?

Answer 1

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

It is good practice to merge the master back into your branch before merging it. What if someone else did something that violated the function you just implemented (as you pointed out)? Or what if someone changed the same code as you and caused possible merge conflicts? I actually suggest merging the master back to your branch very often. This not only does not allow you to spend a day and a half to resolve merge conflicts (although this may be a sign that your branches are too large, this is another story), but it also keeps you in line as the project changes and evolves.

Some may say that you should reinstall your commits on top of the wizard. My short version: I encourage people to open download requests very early in the development process, even if the function fails. This means that you are probably pushing your code to a remote server (e.g. GitHub). To reinstall your commits, you will have to click with the rewritten git history and force to click. Force pushing is a poor workflow decision and should be avoided as it can lead to (almost) permanent damage to your commit history.

So yes, a merger with the host right before you look at the merger, and as often as you can otherwise. If you use GitHub, I even recommend using the new Protected Branches function to force the branches to be updated with the master before merging: