How do I manage multiple development branches in Git?

I have 5 branches of one system - let's call them master, London, Birmingham, Manchester and demo. These differ in only a configuration file and each has its own set of graphics files.

When I do some development, I create a temp branch 开发者_开发问答from master, called after the feature, and work on that. When ready to merge I checkout master, and git merge feature to bring in my work. That appears to work just fine.

Now I need to get my changes into the other branches, without losing the differences between them that are there already. How can I do that? I have been having no end of problems with Birmingham getting London's graphics, and with conflicts within the configuration file.

When the branch is finally correct, I push it up to a depot, and pull each branch down to a Linux box for final testing, From there the release into production is using rsync (set to ignore the .git repository itself). This phase works just fine also.

I am the only developer at the moment, but I need to get the process solid before inviting assistance :)

Two techniques can help:

• submodules: if you have 5 "mains projects", each one composed of:
  • the common code (which get enhanced feature after feature)
  • the special code (specif graphic files or config values, one set for each site)
• template config files

So when you develop a new feature, all you need to do for the other sites to benefit from it is to make sure their respective repo reference the latest common code repo as a submodule. Just a git submodule update to do and you are done.

Plus, with template config files, all you are storing are config values, not the actual config files themselves (they get generated).
That allows you some fine-tuning on each site, without having to "ignore" local modifications.

In conclusion: instead of trying to manage all aspects (common code, config files, special files, ...) in one repo (with all the merge and rebase that will involve), try to modularize your application.

git rebase is your friend.

Make your changes in your master branch as you always do. When you are done, checkout one of your other branches (say, Birmingham) and run git rebase master. git will pull in the changes you made on master between the current commit and the commit on which Birmingham is based. There are good documents on the command out on the interweb. Here are two I found

http://darwinweb.net/articles/86

http://www.eecs.harvard.edu/~cduan/technical/git/git-5.shtml

There are many others. You will find many people talking about the dangers of rebasing. Pay heed to those concerns, but I suspect the benefits vastly outweigh the risks in your case; and knowing the dangers is half the battle.

Another technique:

Once your new functionality is in master, merge back master into all the other relevant branches.

Original state:

o---o-master
    \
     o-London

New commit in master:

o---o---o-master
    \
     o-London

Merge the new functionality into the London branch, with git checkout London; git merge master:

o---o---o-master
    \   \
     o---o-London

Note however that this might be cumbersome, especially if the number of branches increase. I don't know anything about your system, but if you can have all configurations in one branch it would probably be easier (I mean having all the five configuration files and graphics files always present in you file system).

For example with a makefile, you could choose which source files to compile and link depending on your current target configuration. In your case, a makefile can help you to associate graph files and config files with a target configuration.

It would also be nice to be able to build all your configurations without any checkouts in between, would't it?