If you work on a fairly big team and you haven’t checked out gitflow yet, you should. It’s an all-encompassing git branching strategy for dealing with production bug fixes occurring simultaneously with on-going feature development and the like. I did some research on it today to evaluate its suitability for our team, so I’ve decided to write up a post summarizing the gist of the methodology for those of you that haven’t looked into it already.
Using the gitflow branching model, there are 5 (!) different types of branches. I’ll summarize each type of branch, and while reading that, it may be useful to refer to the this diagram illustrating the interactions between the different branch types: http://github.com/downloads/nvie/gitflow/Git-branching-model.pdf
Branch Types
master: The master branch always contains production-ready code. It should have either the same copy of the code that is running in production, or the copy of the code that is imminently being deployed to production. Naturally, this branch is persistent and is never removed. It exists in the central repository (origin), as well as on developer workstations.
develop: This branch is the copy of the code that is being developed for the next prospective release. Small features can be committed directly into this branch, but larger features should be developed in feature branches. This branch is persistent and is never removed. It exists in the central repository (origin), as well as on each developer workstation. This is the branch that the CI process uses.
features: These branches are named after a particular feature. They are created (based on the “develop” branch) when work on the feature begins, and incremental work on the feature is committed to that branch. They exist only on developer workstations. If multiple developers are working on the same feature, they push/pull to/from each other’s feature branch, it would seem. When work on the feature is code-complete, this branch is merged into the “develop” branch, and then the feature branch is deleted. Merging a feature branch into develop signifies that the feature will be included in the next release. By contrast, feature branches may be long-lived, and may not be merged into develop until several releases have passed, for a large feature. Once a developer has installed gitflow, they can create a new feature branch by typing ‘git flow feature start [feature-name]’. (That just does ‘git checkout –b [feature-name] develop’.) When the feature is done and ready to be merged into ‘develop’, the developer types “git flow feature finish [feature-name]”. (This does a ‘git checkout develop’, ‘git merge –no-ff [feature-name]’, ‘git branch –d [feature-name]’, and ‘git push origin develop’.)
releases: These branches are named after a particular release version: a major (2.0) or minor (2.1) release version. They are created (based on the “develop” branch) when all the features for the next release are code complete in the “develop” branch. While the release is being tested, bug fixes are made into this branch. New functionality, however, will continue to be made in the “develop” branch (and associated feature branches), and will not be included in the release. (These branches are created at the same point in the development cycle when a “code freeze” might be declared in a development shop that doesn’t use any sort of branching.) These branches are created with ‘git flow start [version]’, which it seems like it must just do a ‘git checkout –b release-[version] develop’, and then you probably still need to manually increment any applicable version files and then commit those changes. When the release has been tested and is ready to go to production, it is merged into master, and also merged back into “develop” (so that any bug fixes made will be applied to future versions as well), then the branch is deleted, all with the command ‘git flow release finish [version]’. (This does a ‘git checkout master’, ‘git merge –no-ff release-[version]’, ‘git tag –a [version]’, ‘git checkout develop’, ‘git merge –no-ff release-[version]’ and ‘git branch –d release-[version]’.)
hotfixes: These branches are created for urgent bug fixes on the version that’s currently in production, and they are normally named after a point release (eg. ‘hotfix-1.2.1’). They are very similar to release branches, except that are created from master. They are created with ‘git flow hotfix start [version]’, then later merged (into master and develop) and deleted using ‘git flow hotfix finish [version]’. These commands do very similar things to their equivalent release commands, as one might expect.
More information
Original post on the branching model is here: http://nvie.com/posts/a-successful-git-branching-model/
Gitflow tool is here: https://github.com/nvie/gitflow
Introductory post on basic gitflow usage is here: http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/
Conclusion
If I was on a bigger team, I think this would make a lot of sense, but for our small team (three developers, including myself and our manager), I think its a bit of overkill. We are probably going to adopt a limited subset of this methodology: We will create hotfix branches and perhaps occasionally feature branches for very large features, in addition to the two permanent branches (master and develop), and we will probably use the gitflow tooling. However, we probably won’t use specific release branches, and our use of feature branches will probably be limited at most (and they would exist on github for the duration of their life, contrary to the gitflow methodology).