Question

According to http://gitster.livejournal.com/42247.html, branches can be either:

• “topic” branch = which contains all cohesive changes related to a single feature/bug-fix/experiment/etc
• “integration” branch = which picks/and chooses which topic branches to merge changes from.

I have topic branches x, y, and z

I have customers A and B which each want/paid-for a different set of features.

customer A wants x and y. That’s easy enough:

git checkout A
git merge x y

and voila! I have what I needed. But how do I automate/record which topics ought to merge into A? This is what I did. In my config file I have:

[branch "A"]
    remote=.
    merge=refs/heads/x
    merge=refs/heads/y

and so now every time I want to update branch A, I simply:

git checkout A
git pull

and it automatically knows which branches to pull.

Is this a good idea and/or bad idea?

More specifically this is what I have in .git/config:

[branch "A.test"]
    remote=.
    merge=refs/heads/x
    merge=refs/heads/y

So that branch A (which is the production branch) never accidentally pulls any changes.

Answer 1

You probably don’t want to do that. Once x and y are merged into A, you’ll have little else to merge from them in the future. Your work flow might need that though. Check out git-flow.