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.

  • Best Practice: How to handle code differences for iOS App when creating free and paid version?
  • Prevent pushing of commits that add to closed branches
  • Why does `git checkout <branch> <file>` stage the change?
  • Git branching model, what is the benefit of having a development branch?
  • How to recover a merge commit after a rebase on the same commit?
  • GitHub: What is a “wip” branch?
  • 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 🙂

  • How to connect OpenShift with a private BitBucket Repository
  • how to start Mysql in git bash in windows 8.1
  • In git, editing a historical pre-pull commit after the pull causes divergence from origin
  • Updating a git mirror of an SVN repository
  • PHP: different result when running script via HTTP and in command line
  • How to check real git diff before merging from remote branch?
  • 3 Solutions collect form web for “How do I manage multiple development branches in Git?”

    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

    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:


    New commit in master:


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

        \   \

    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?

    Git Baby is a git and github fan, let's start git clone.