Playing with Branching Strategies (Part-1) :

abstract business code coder
Reading Time: 4 minutes
Code Branching Definition | What Is a Branch (Version Control)? | Perforce

Hello Reader’s I hope you all are doing so well. So in this blog we are going to learn about Branching Strategies So stay tuned.

They are very interesting from many different aspects. To begin with they are a good indication of the theme structures of the frequency of the deployments of technical capabilities of test coverage.

So; we are going to explore branching strategies and see which one are you currently applying and whether you should stick with it or may be trying to move to something else.

So; let’s start with one by one.

1. Trunk Based Development:

Single Branch :

The easiest strategy by far is trunk based development. We have single branch you know the main line or trunk or master etc. And everybody is cloning that branch making some changes locally and pushing directly to the main line no branches, no pull request, no other things just working on features or bug fixes and as soon they are done pushing them back to the main line i.e the easiest branching strategy. There is nothing to do nobody needs to merge anything, nobody needs to maintain anything. We just push directly to the main line.

High Team :

When doing trunk based development as a matter of facts it’s not everything else is very very hard. We need to have excellent cold call coverage. We need to be really proficient in writing tests probably doing some kind of testing in advance before writing code we need to have strong automation, we need to deploy automatically somewhere and so on.

Feature :

In trunk based development is that we need to use switcher toggles. If we are pushing changes to main line frequently and that is the most likely reason why somebody is using trunk based development then we need to make sure not only that changes are tested and that they are valid and that they are working and so on.

Continuous Deployment :

Trunk based development is the true enabler continuous deployment. If you are not doing trunk based development you are not truly applying continuous deployment. You are most likely doing continuous delivery or continuous integration or etc. but in most cases continuous deployment is strongly associated with trunk based development.

2. Feature Branching or GitHub Flow :

One Branch :

If we want to work on something on some feature or a hotfix we create a new branch we tend to work fast when applying feature branching because features are typically split into very small chunks so that it does not take much time to write code for something and once we are finished we create a pull request we review that pull request we run some automation as part of that pull request and we merge that branch back to the main line.

Short Delivery :

The important thing about feature branching is that we work on very small chunks of something and we have very short delivery cycles typically a team working with future branches would finish working on a feature within a day or even some hours sometimes couple of days and that means that not only code is written and tests are written but also pull request is created.

Continuous Delivery :

When using feature branches typically we are doing continuous delivery or continuous integration. Continuous delivery is more often than not if you are not that confident in what we are doing it could be continuous integration.

Pull Request :

Pull request are a must and we create pull request not only when we are finished working on something but whenever we want feedback so it could be in the middle of development i want feedback from the other people so you can create a pull request and get the feedback and once all the things are done goes back to the main line.

3. Forking Strategy :

Forking Repositories :

The major difference is that we do not create branches from the main line we fork whole repositories work on this and then and create a pull request and back to the upstream.

Mostly Open-Source :

The most common use case for forking is open source. In many cases actually if you want to contribute to an open source project you do not clone the repository of that project instead you fork the repository create a copy of that repository and then work on in it.

Conclusion :

So; In this blog we have seen some branching strategies that we are used in project. We have also seen what is exactly working they are. So stay tuned for next strategies.Thank you for being with me.

Happy Learning

Reference :

Click here

Written by 

Mayuri Dhote is a Software Consultant at Knoldus Software. She has completed her MCA from VIT University. She has very dedicated towards her work. She has always ready to learn new things. Her practice area is Devops. When not working, you will find her writing poems and poetry.