A successful Git branching model
Git tracks the changes made to the files, so you have a record of what has been done, and you can revert to specific versions should you ever need to. Git also makes collaboration easier, allowing changes by multiple people to all be merged into one source. Git really changed the way developers think of merging and branching.
The model that is presented here is essentially no more than a set of procedures that every team member has to follow in order to come to a managed software development process.
1. Decentralised but centralised
The repository setup that works well with this branching model, is that with a central “truth” repo. We will refer to this repo as origin, since this name is familiar to all Git users.
<image>
Each developer pulls and pushes to origin. But besides the centralised push-pull relationships, each developer may also pull changes from other peers to form sub teams. For example, this might be useful to work together with two or more developers on a big new feature, before pushing the work in progress to origin prematurely. In the figure above, there are sub teams of Alice and Bob, Alice and David, and Clair and David.
2. The main branches
The central repo holds two main branches with an infinite lifetime:
- master
- develop
The master branch at origin should be familiar to every Git user. Parallel to the master branch, another branch exists called develop.
We consider origin/master to be the main branch where the source code of HEAD always reflects a production-ready state.
We consider origin/develop to be the main branch where the source code of HEAD always reflects a state with the latest delivered development changes for the next release. Some would call this the “integration branch”. This is where any automatic nightly builds are built from.
When the source code in the develop branch reaches a stable point and is ready to be released, all of the changes should be merged back into master somehow and then tagged with a release number.
3. Supporting branches
Next to the main branches master and develop, this development model uses a variety of supporting branches to aid parallel development between team members, ease tracking of features, prepare for production releases and to assist in quickly fixing live production problems. Unlike the main branches, these branches always have a limited life time, since they will be removed eventually.
The different types of branches we may use are:
Feature branches
May branch off from:
develop
Must merge back into:
develop
Branch naming convention:
anything except master, develop, release-*, or hotfix-*
Release branches
May branch off from:
develop
Must merge back into:
develop and master
Branch naming convention:
release-*
Hotfix branches
May branch off from:
master
Must merge back into:
develop and master
Branch naming convention:
hotfix-*
Source: