IPNET

Git Strategy

2 min read

This branching strategy is intended to describe a way to simplify the process of working together on the same code base using git and a scm (Source Control Management) environment using git.

In our case it will be mostly done using azure devops. But that is not relevant to this document. The SCM is useful because you can centralize setting up policy on branches and make use of the pull request feature. These are not inherently available in vanilla git.

Structure

Main branch

I suggest to use only 1 main branch. This branch must at all times reflect what is in production. This does not mean that the branch it's latest commit should also be the version that is in production. But it does mean that there is a commit in this branch that is currently in production.

Main should also be our source of truth of the state and past states of our application. So a policy should be set so that the branch can only be advanced with commits through pull requests. These should be fast-forward squash commits.

Caveat: It is possible that a state can emerge when the main branch has to be fixed and a pull request won't do. Only seasoned engineers should attempt a repair. And all branches should rebase accordingly taking in account the branching hierarchy.

Feature and bugfix branch

Feature branches is where you will develop your feature and in the bugfix branch you will develop your non priority bugfixes.

 

Error loading the extension!

 

It is wise to regularly rebase on the branch that is higher in the branching hierarchy. You should always rebase on main before merging with main via a pull request.

The merge should be a squash commit to simplify identifying changes applied to the code base as 1 atomic unit.

Hofix branch

 

It is possible that while continuing to commit work to the main branch that a bug is found in production while the current state of the main branch is not ready for deployment to production. The process then should be as follows.

  • Branch from the commit in the main branch that has been deployed to production into a hotfix branch.
  • Fix the bug in this branch, preferably create a branch from the hotfix branch and follow a pull request procedure.
  • If the hotfix branch contains the fix you can deploy this to production.
  • The fix should be cherry picked and put on the latest commit of the main branch.
  • Once the main branch is deployed the hotfix branch can be deleted

Remark: If after deployment of the hotfix branch the bug is not fixed or another issue arises, work can be done on the hotfix branch and the fix must also be put on the latest commit of the main branch.