Merge dev branch into master VS merge master into dev

Question

I am confused what will happen if I merge master into dev, and what's next to do? Should I just merge dev into master again? in that case, did the master head just simply move to the F' merge commit?

Answer 1

Merging master -> dev -> master is not quite the same as dev -> master -> dev. The differences are subtle, and unlikely to affect your code, but may be an issue when reviewing history or reverting merges.

First, here are some outputs from git (using git log --graph --oneline --decorate --branches) that illustrate these scenarios.

Prior to merging:

* 4da7550 (dev) E
* d80d7a8 D
| * 5a5dde8 (HEAD -> master) C
| * 880a096 B
|/  
* 59903a3 A

Merging dev into master, then master into dev:

*   88bda7a (HEAD -> dev, master) Merge branch 'dev'
|\  
| * 4da7550 E
| * d80d7a8 D
* | 5a5dde8 C
* | 880a096 B
|/  
* 59903a3 A

Merging master into dev, then dev into master:

*   e0ef175 (HEAD -> master, dev) Merge branch 'master' into dev
|\  
| * 5a5dde8 C
| * 880a096 B
* | 4da7550 E
* | d80d7a8 D
|/  
* 59903a3 A

The main difference here is that commits in each scenario are reversed. In the first case, the master branch is on the left and the dev branch is on the right. In the second case, it is reversed.

Why does this happen?

When you merge one branch into another, git creates a commit with two parent commits. The first parent will be the current branch you are on, and the second parent will be the branch to be merged.

When we merged master into dev first, the dev branch was parent 1. When we merged dev into master first, master was parent 1.

Does it matter?

Not particularly, as long as you're aware of it. This isn't normally a problem and won't affect the code. It does make your git history a bit harder to read, as in the second case we have master on the right, making it look as if dev was the base branch.

The only practical difference is that if later on you decided you made a mistake and want to revert the dev branch changes, your command will change.

If I had merged master into dev first, I would type:

git revert -m 2 <merge commit ref>

If I had merged dev into master first, I would type:

git revert -m 1 <merge commit ref>

-m <n> tells Git to revert a commit, and keep the nth parent

One way to avoid this is to avoid fast-forwards when merging into master, by using --no-ff. This will create another merge commit, with the parents in the normal order.

There's also no real need to merge master into dev at all, unless you specifically need changes that are in master to continue your work. In that case, you would also expect to have further commits on the dev branch and not just immediately merge it back into master.