My work is in the process of switching from SVN to Git and we are re-evaluating how we use branches and tags.
We have seen the model which uses master as the always stable version where tags are used to identify releases and a separate development branches are used for unstable code (http://nvie.com/posts/a-successful-git-branching-model/).
We like this method of development, but it doesn’t appear to allow for applying hotfixes to an already released version.
Our product is installed multiple clients servers and each may have a different version installed (for various reasons beyond our control). Today we manage our release using branches and master is used for development.
For example we might have 3 clients on different versions:
- Client A – v1.1
- Client B – v1.2
- Client C – v1.3
If a critical bug is found in v1.2, we fix it in the v1.2, v1.3 and master branches and update clients B and C. We don’t create a new branch for these changes, but technically they would be version v1.2.1 and v1.3.1.
We can’t see how to switch to using only tags for releases when we need to be able to create a v1.2.1 when v1.3 is already out the door.
Can anyone recommend a model that would suit us better than creating a branch per release and doing development in master?
You can create a new branch based off an old tag. If you find a critical bug in v1.2 when you’ve moved on, just create a new branch from the v1.2 tag, fix the bug there, tag it as 1.2.1 and then cherry pick the fix into all other tags (now branches) that you’re maintaining.
Even if you weren’t doing your stable releases in
master, this would still be applicable.