GitFlow Branching Model

Standard

Code branching could help large development teams to manage code base efficiently and to avoid unnecessary dependency of feature launches. When code branching is done right, team leads and development managers could efficiently manage the development of features and respond to issues reported promptly. However when code branching is poorly designed, not only development team cannot build features, the deployment manager would also not able to make a deployment.

GitFlow Branching Model is a branching strategy not too complicated to comprehend yet it could cover most development teams need.

gitflow branching model

Master Branch

Master branch consists of the updated set of source code as per production. This is the most critical branch and should be guarded against any unreviewed commit into the branch. No one should commit directly into Master Branch. Master Branch should only be used for branching out for production hot fix and not any other purposes. There is one exception during the early phase of the project, Master Branch will be branched out as the base for Development Branch. Once a system has gone live, the primary purpose of Master Branch is to serve as a foundation for any production hot fix. Master Branch is especially useful when there are multiple development teams making multiple production releases within short period of time. Master Branch will serve as the most updated branch for any development team to work on a production hotfix.

Development Branch

Development team branch out a Feature Branch using Development Branch as base. Once a Feature Branch is finished worked on, the code in Feature Branch will be merged into Development Branch. Development Branch could also be seen as an integration branch. If there are multiple develoment teams working on multiple features parallely, here is where multiple features get merged. Any conflicts between feature branches must be resolved and a merged version of the source code in Development Branch is expected to be stable. Ideally, developer should not commit directly into Development Branch, however there could be minor changes to the code base that it would be too much of overhead to create a new Feature Branch for such change, for example an improvement of an utility method or an update of a configuration value.

Feature Branch

Feature Branch is branched out from Development Branch for specific team of developer or individual developer to work on a particular feature. This is the branch where most check in happens for developers. Multiple developers would check in to the same branch if they are working on the same feature. Once a feature is finished worked on, developers would merge their code back into Development Branch. However, prior to merging a Feature Branch into Development Branch, it is highly recommended for developers to merge the latest code in Development Branch into the Feature Branch. If possible, do it from time to time. This process is sometimes called Forward Integration and sometimes called Rebase. The purpose of doing a Forward Integration is to reduce the risk of a big-bang merge directly into Development Branch. Once a Forward Integration is performed in Feature Branch, it would be relatively easy to merge code from Feature Branch into Development Branch. Additional note for Feature Branch is it should not be running for too long. If for whatever reason (such as stakeholders started changing their mind on the requirement after development started), Forward Integration need to take place from time to time to reduce risk on a big-bang merge into Development Branch.

Release Branch

A Release Branch is cut when there is a planned deployment to production. When the deployment manager deploy code into Staging or Production environment, the source code would come from a Release Branch. QA would be testing against the code in Release Branch and developers would fix bugs and check in the fixes into Release Branch directly. On the next deployment to Staging, QA would be testing the latest bug fix from Release Branch until QA is satisfied with the quality of the feature (or the quality of the system as a whole). Then, deployment manager will get the code in the same Release Branch and deploy them into production. Once the deployment to production is completed, the source code in Release Branch need to be merged back into Development Branch for future development and Master Branch for any hot fixes.

Hotfix Branch

A Hotfix Branch is only required when there is a production hotfix that need to take place very quickly and get deployed back into production. A Hotfix Branch is branched out directly from Master Branch to ensure the Hotfix Branch consist all of the latest stable features that have been release to the users. Development team would work on a Hotfix Branch usually in a relatively short period of time, then get the code tested and deploy the code back into production. Once the code is deployed into production, the changes in Hotfix Branch have to be merged into Development Branch for future development and Master Branch for any hot fixes.

Visual Studio (Team Foundation Server)

In .NET development using Visual Studio (TFS), code branching and merging functionality is rather limited compared to the rest of the open-source world hence most .NET developers use simple 1 level branching model.

For GitFlow Branching Model to work in Visual Studio development, the development team need to make a conscious effort to follow the branching and merging guideline.

One last thought…

Code branching is an overhead if the development team is not large enough or the system is not complex enough to require branching. If you have a small team (let’s say 2-3 developers) or a relatively small system, I suggest you simply use a source control for repository purpose and do not over complicate your development process with unnecessary code branching overhead.

Leave a Reply

Your email address will not be published. Required fields are marked *