Git branching Model

While working with the git and Github  it is very important to have a consistent branching model. Developers create many branches so they can work with the code. But having a consistent branch model for our development saves a lot of time. This article talks about the branch model that fits most organisations. 

Every team will have 2 main branches develop and master. Parallel to the master branch , another branch exists called develop. So most of the times develop is the one that code gets pushed always. 

Master - The origin/master is the main branch where Source Code always reflects to the production ready state.

Develop - Also origin/develop is the main branch where the source code which reflects to the latest delivered development changes for the next releases. Some people call this as the “integration branch”. This is the branch where all the nightly builds use to build and make sure the code is set.

When the source code in the develop branch reach to a stable point and is ready to be released then all changes are merged from develop branch to the master branch. Then master will be tagged with a release number and deployed.

So any changes done to the master branch is a production release automatically. We can use a Git hook or a Jenkins build to identify changes to the master branch, build it and release to the production automatically.

Other helping branches

Other than the master and develop branches there will many other branches that will be created and deleted based on the requirements. These branches are used to aid parallel development between team, feature development, production release , bug fixing, live production problem solving etc.

These branches after some time will eventually be removed. These branches include

Feature Branches

Release Branches

Hotfix Branches

Each of these branches are defined keeping specific purpose in mind and a are bound to strict rules like which branch is the parent and which branch is the target. 

Feature branches - Feature branches or sometime called as topic branches are used to develop new features for the upcoming releases. These release can be any time but based on the priority of the feature , a feature branch is created from the develop branch. The parent branch for a feature branch is the develop branch.

The target branch will not be known during the time of the feature branch. It may either merge back to the develop branch or to another feature branch or it can discarded completely ( in case if the feature is not required ).

Release Branch - Release branches are created so that they can support a new production release. The release branch will be created from the develop branch. The develop branch in turn should contain all the features, changes that are agreed for that release. All these changes and features are developed and then merged back to the develop branch. The changes once merged to the develop branch are then merged back to the master branch. Every changes to the master is a new production release by default.

Basically forking a branch from the develop branch for a release starts a release cycle. At this moment no new changes or features can be added to the release branch at this point. Only bug fixes, documentation, testing, security checks and other release oriented tasks should go in this branch. Once this is ready, the release gets merged into the master and tagged with a version number. It should also be merged back to the develop branch which may be progressed since the release was initiated.

Using a separate dedicated branch to prepare releases makes it possible for one team to work only on this branch and polish it for the current releases and other teams work on new features for the next releases. 

HotFix Branch - These branch are very special as they are not planned before. These branches are created from the master branch in order to solve a production issues. When a release is done , and if the team identifies a bug or problem they create a branch from the corresponding tag on the master branch that marks the production version.

Once the bug fixing is done for the hotfix branch, it is then merged back to the master branch with a tag and released to production. The changes are again merged back to the develop branch to fix the same bug in the develop branch.

More to Come, Happy Learning