git workflow for the bikesoup project

I have been one of the many converts to git and try to use it whenever possible. So far this has been mostly for smaller project, open source projects, Fedora and a little bit at work.

bikesoup is my first bigger project using git. I started with initial development on the master branch and created feature branches which got merged back into master. Before going live for the first time I created a live branch. This is pretty much what you would do in subversion too, maybe with the exception of any feature branches.

Once the site went live I created a feature branch off master for each issue in bugzilla I am currently working on. When I am happy with the fix I merge it back into it.  And when the feature goes live it the feature branch is also merged into live. The diagram below shows this process.

When first working like this I had all kind of problems when I merged into live. When you branch a feature and then only work on this feature before you merge it back into master git uses fast-forward merging, which messes up the feature branch. If you merge this feature then into live you merge in fact master, which is probably not what one wants. So now I use --no-ff on all merges.
The nice thing is that you can go back to feature branches. Sometimes a bug gets reopened and I don't want to create a separate branch for this. Then I can check out the original feature branch add the fixes and merge back into master and then live.
To make it a bit more interesting I have also a hot-fix branch off live for things that have to fixed fast because the site is broken. This gets also gets merged back into master. And some other branches which track changes to configurations in live and master which don't get merged between the main branches.

So, how does this look in practice?

The git-set-file-times is necessary, because git can mess up the file times when switching branches, which messes up the rsync of the symfony deploy script. The script sets all file times to the last commit times.

If you are coming from subversion (or worse) it isn't easy how fast the branching and merging is. One way to visualize is the diagram to the right, which just shows the branches of one day. Some of these just contain a few line changes.

Another way to describe it is "two seconds", that is how long the script above takes (just the branch switching, branching and merging, without the time for bug fixing and upload of course).

So, whoever is still not using git: try it on a small project and I promise you will fall in love with it soon.