We follow a branching model that is a very simplified version of http://nvie.com/posts/a-successful-git-branching-model/. The main difference is that we do bug fixing and make releases from the master branch, and only use release branches for older, still maintained versions. It is suggested to read this post first, to get an larger view on the ideas behind our branching model.
There are two main branches, master and develop.
- master is the branch for adding bug fixes. This is the code that will become the next bug fix release.
- develop is the branch for adding new features. This is the code that will become the next major or minor release.
develop has been branched off from master at one point, and from time to time, bug fixes that have been applied to master are merged back into develop:
$ git checkout develop $ git merge master $ git push
It is suggested to do that merging and pushing in a single, separate action, so that "real" work on the develop branch isn't get lost in the large commit messages of the merging.
Even though develop is the branch for new development and adding features, larger features should be developed in a topic branch that is branched off develop:
$ git checkout develop $ git checkout -b newfeature
This is to avoid breaking code in develop. This is important, because develop is used for the next minor release, which will be created at a set date. To avoid having to revert commits if develop is unstable when the next release is near, such development must be done in topic branches, that can be merged back to develop, once they stabilized:
$ git checkout develop $ git merge newfeature $ git branch -d newfeature
These topic branches can be private, or public if other should participate in development or testing. For creating public branches, see http://www.horde.org/development/git#creating-managing-remote-branches.
Topic branches are especially important when developing code that breaks backward compatibility, if it has not been decided yet whether the next release will be a major or minor release.
Release branches are maintenance branches for older releases. Once the release process for a new minor/major version is starting, the current version's code is branched off master into a release branch, before the current develop branch is merged back into master for the new version:
$ git checkout master $ git branch FRAMEWORK_4_0 $ git merge develop
Since we always maintain the two most recent minor versions with security fixes, there will always be 3 active branches (topic branches aside) at the same time. master, develop, and the release branch for the last minor version.
If for example we already had 4.0, 5.0 and 5.1 releases and are now working on the 6.0 release, we would maintain develop, master and FRAMEWORK_5_1 branches.
[gitflow https://github.com/nvie/gitflow] is a tool for managing the branching model of Vincent (nvie). If necessary, we might be able to fork and adapt it to our simpler needs.