views:

36

answers:

1

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?

+1  A: 

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.

Jefromi
I think I see what you mean.By match and keep separate I meant that I'd like to synchronize their code and then continue running with the "experimental" as I still have experiments to continue with but I made a wide enough change on master that it would be blasphemous to continue with being sure I had the same code.Wonderful post, that is and will clear up a lot for me.
jphenow
@jphenow: In that case, you should keep the experimental branch around even after you merge into master (e.g. `git checkout master; git merge experimental; git checkout experimental`). However, I'd caution you against using a single experimentation branch for a variety of experiments - they should really be on their own branches, so you can merge them separately.
Jefromi
Oh of course - I have a different branch for each experiment subject, but I looked at each branch and it seemed like something was changed on the master that would make it awfully weird to continue on the experimental without getting some of the master changes.
jphenow
@jphenow: Generally, when a topic branch needs a particular change from the master branch in order to continue, the ideal workflow is to merge from the topic branch which introduced that change, rather than from master itself - this avoids merging a bunch of irrelevant stuff from master.
Jefromi