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.

  • Commit to develop branch directly in Git Flow?
  • Git - transferring all commits to another branch and creating a new master
  • How to Determine the Work Items Fixed in a particular TFS Build when using Branches?
  • Retroactively treat line of Git commits as a branch
  • Get git current branch/tag name
  • Svn to git: How to deal with our not-standard, probably wrongly branched svn
  • 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 🙂

  • Is GIT a good solution for large projects like Laravel or projects using Smarty Templating
  • Git Commit works with XCode beta but not with normal version
  • can commits by TWO people have the same hash?
  • Merge conflict, when branches aren't modifying the same line
  • Build once, deploy many using gitflow and gitversion
  • Adding git diff in push notification mail
  • 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

    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?

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