Git branching strategies

Why Branching ?

Branching strategy is required no matter how small your development team is. Without a branch created, all your developers would clone the master branch , and do the necessary changes . When they are ready with changes, they would push the code. Irrespective of whether they use PR or manual push, it becomes increasing complicated to merge and commit. With multiple developers commit, the developers would spend lot of time merging the code, a slight mistake  might result in losing code or overwriting previously committed code, If the continuous integration and deployment is enabled , then deployments to various environments would be affected and time consuming , it becomes even more complex when you have multiple releases and need to test the new changes before deploying to prod.

Developer Specific Branching

In this approach, you have the master branch , which is the branch you would use to deploy the code to various environments including production.

Now, each of your developers, take a new branch for themselves , develop features , fix bugs , commit the code, push to their own branches. Whenever the changes are complete, they would then raise a PR to move code to master branch, finally deploying the code for testing

One key point here, is the developer branches needs to be updated (merged) from master branch everytime other developers PR gets approved. Delaying this update, might result on lot of conflicts needing manual merge thereby adding to more efforts.

This strategy works really well when you have a small team.

A slight variation to this could be where in you can have two more levels before master , say Develop and QA , this gives you more control on code quality, and allow more freedom on testing 

Environment Specific Branching

This strategy is based on the environments the application deploys to. At any given point of time the branches resemble the code deployed on corresponding environments. 

All the code changes related to a feature or a bug would be done in a separate branch and then merged into the environment we wish to deploy, typically through a pull request and if you have a Continuous integration enabled, a feature when ready would get deployed to the env as soon as the pull request is approved and merged.

To ensure the integrity of the code and the branches, ensure your team do not commit to any environment branch directly. Also, you should never merge one environment branch with another.

As you can see here, there are three branches master , QA and dev , each of them corresponding to environments. Now,  let’s say you have a bug that needs a fix and deployed to  server. The developer would create a new branch from master ,

Feature – Bug Branching

The feature bug branching strategy is not only reliable than directly editing master copy, but it also aligns with the agile backlog and allow development work at granular level.

In a feature branching approach, when you start working on  a feature or a bug , you take a branch of the repository to work. 

The advantage of feature branching is that each developer can work on their own feature and isolated from other changes going on. The developer can pull the new changes from the main branch at their own frequency , ensuring they dont break the development of the feature, 

When features are complete and developers want to integrate the code, they would raise the pull request to merge the code. 

Sprint Branching

Fork Branching

The fork workflow pattern gives teams their own space to work in whatever way they are used to with a single integration point between the two repositories – a pull request. Over communicating is imperative within the pull request description. The teams have had separate communication streams before a pull request has been issued, and highlighting the decisions that have already been made will speed up the review process.

Of course one benefit of the fork workflow is that you can direct comments to contributors of the origin repository, as the permissions cascade downwards. From the point of view of the origin repository, you have the control to delete forks when they are no longer needed.

Integration Branch

Integration branch is applicable for large teams who implement new features for a complex individual parts of the application. In such scenarios , the deployment to production would generally require to integrate the features done across multiple teams and collectively deploy.  In this instance, the risk of integration is high and requires to undergo a more detailed QA. the Integration branch reduces the risk of failure  

Versioning Branch

If you have a repository that you not only run in production but allow self hosting , then using version branches can give your team the flexibility to support users who do not, or cannot move to new version immediately.

A repository using version branches will have one branch per minor version of the application.. Version branches typically follow a naming convention to include the word “stable” and drop the patch number from the application version: e.g. 2-3-stable to make their purpose and reliability obvious to end users.

Git tags may be applied down to the patch version number of the application, but version branches are not that fine grained. A version branch will always point to the most stable commit for a supported minor version.

When security patches or the need to backport functionality come along, put together the commits necessary to work for older application versions that you support, and push them to your version branches respectively.

Hybrid Branching

Now, depending on the team size or the project needs, note that you can use a hybrid branching strategy such as , you can have a  combination of feature branching with environment branching . This allows your team to have features developed and still you control the deployment to various environments

In another scenario , where you have the product team and the integration team

Product team owns the main repository for development of product features while the integration team would modify /integrate the product with other 3rd party system. ‘

The Integration team may not have necessary permissions to edit/update the product repo. In such cases, the fork Strategy with feature-bug strategy would provide the necessary freedom for integration team to modify the product code and then raise the Pull request for product team to review /approve.