When it comes to Git branching strategies there are a lot of different ways to tackle. The most important part is to have the entire development team on the same page and following the same rules and guidelines. Consistency is key as it provides a good way to audit trail changes and have a good way of seeing what task caused what change.
In this article we will look at best practice tips that you could employ in your development team’s strategy. Please take these tips and adapt them to fit your release cycle and coding practices.
Environments matching branches
If you are planning on having CI (Continuous Integration) / CD (Contentious Deployment) then one of the most important things you can do is make sure you link up branches to those environment pipelines. For example, your ‘Master’ branch should be linked to the live deployment build and release pipelines. If you have a QA and Development environments then you should have separate branches named to match the environments and link them to their corresponding pipelines.
Branch — Environment
Master — Live
QA — QA
Dev — Development
When working on a feature you should branch from the branch you eventually want to merge into. For example if you are working on a new page for your website that will go live. You should branch from Master and work on your page feature. It can be named something like feat-new-page. To test on development you then merge into the Dev branch. Once testing passes you can merge the feature branch into QA and then to master when that feature is ready to deploy.
The above example is good for agile teams as any feature should be independent and ready to deploy once tested. However for more waterfall teams you can create a feature branch from the lowest environment. For example branch from Dev to create your new page. Then once the feature is ready merge into Dev. Once all of the new features are tested on Dev, Dev can be merged into QA. Once all the testing is done on QA it can be merged into Master to deploy to the live environment. In this method you will most likely be doing one big release of several features at the same time.
The first two tips are very common things that teams do in a very similar form. Branch naming convention’s however, can differ greatly from team to team. Every team has their own way of naming feature branches. There is not rule you should follow however, what is important here is that every one follow the same format. It is also important to have a format for your team and project. The reason for this, it can make it easier to track back to changes that have happened.
Things you can try to add to your format are things like feature folders where all features go. A bugs folder for any bug fixing branches. When it comes to naming, some form of linking to the ticket system you may be using to track development work. Azure DevOps, Jira, Trello and others all have some sort of unique identifier that links back to the Product Backlog Item (ticket/card) that the developer is working on. Having that number in the branch name can help link work to branches.
I hope that these branching tip will help your team work better together and have more consistency. It should improve code quality and a better audit for any changes to the code base.