Question

So I created a new branch from master and eventually merge the changes back, only some changes seemed to merge and it would seem I merged in one direction. Eventually I just decided to be sure master received all the ‘experimental’ changes then I deleted the experimental branch and made a new one. So this question is turning into a few questions suddenly:

1) How do I match up branches but keep them separate?

1a) Is that bad practice to not just make a new branch?

2) Why were the branches not the same after after one merge?

2a) Am I only supposed to call a merge on the one that I want to have all of the changes?

Answer 1

With respect to the practical, a merge is definitely a one-way operation. It merges one branch into another. The resulting history after merging experimental into master would look like this:

- o - o - o - o - o - X (master)
   \                 /
    o - o - o - o - o (experimental)

So after one merge, master contains all of the changes made in experimental, but they are clearly not the same.

I’m a little confused about what exactly you mean by “match up but keep separate”. It’s common practice to make a topic branch for some specific purpose (feature, bugfix…), then merge it into everywhere that entity is needed. For example, a bugfix could belong in two old maintenance releases as well as the current master, so it’d get merged into all three.

I think this post on Junio Hamano’s blog (he’s the current maintainer of git) is one of the best explanations I’ve found of exactly when you should merge, and when you shouldn’t. It should answer the bulk of your philosophical questions.