Reputation: 57202
I've been looking at the gitflow workflow a bit http://nvie.com/posts/a-successful-git-branching-model/, and it makes sense and is very similar to what I've done in the past. I've done things a little differently when it comes to releasing and hot fixing and wanted to ask about the advantage or disadvantage of they way gitflow branches vs how I've proposed.
Typically when I create a release branch, say for release 1.0.0, I'll name the release branch release-1.0.x, not release-1.0.0. Once I create the branch (but before the code is released), the version will be 1.0.0-SNAPSHOT for any last minute fixes. When I release, I create release version of 1.0.0, tag it and merger to master. Now rather than deleting the release branch, I increment the version to 1.0.1-SNAPSHOT. This effectively becomes a long-lived hot fix branch for the release 1.0.x series. If I find a bug in production, I'll fix it on this branch, cut a 1.0.1 release version and increment the version to 1.0.2-SNAPSHOT, and so on.
The downside is that release branch exists for as long as this release is the current release. The upside is that I don't need to create new hot fix branches if there's a bug, and the branch already exists.
So my question is am I missing any major issues here by not having the hot fix branches and doing it this way?
Upvotes: 0
Views: 1250
Reputation: 651
We have adopted the nvie model at work and it works very well.
The hotfix is only used for minor patches to the released software - and will have a very short lifetime before they are merged to master and deleted. Meanwhile the develop branch is used for work towards major improvements.
The (minor) advantage I see to the nvie model is the short livespan of hotfix branches. In a team of people, I can see the advantage of having a hotfix branch ready for them to use if needed.
Upvotes: 1