Hello Readers.. I hope you all are doing so well. So lets get started with another Remaining branching strategies. So stay tuned.
1. Release Branching :
Release normally tend to be longer lasting weeks or even months.
Since different teams might be working on different releases then we have a branch for each release.
One Branch:
One team would be working on one release another team and another release typically we would have additional branches one for each and that’s were situation gets a bit more complicated already because we are merging hot fixes and those release to the main line and whenever we merge something to the main line we need to make sure that all the currently open branches are also updated.
Low Frequency:
Release branches are typically associated with low frequency deployments it is often used by teams who deploy once every couple of week and maybe once a month. If you want a single word that would associate the way how we work with release branching that would be waterfall.
No Continuous Integration:
We have merge conflicts we have deviation and we have delayed integration there is no continuous integration when you are using release branches. Because we have different branches and it takes a lot of time untill they are merged back to the main line and it takes even more time too.
2. Git Flow :
Branches And Branches:
Git flow is when things get really complicated and silly in a way typically when using git flow we would create a development branch and from that branch we would create feature branches like feature 1 , 2 and so on and then we create a release branches also from the dev branch and those release branches needs to be merged to dev branches as well so that it’s more or less sometimes eventually up to date. And release branches are also merged to the main line because main line is the reflection of production.
3. Environment Branching :
If you are in very worse position than of those that we read about and the worst one is environment branching that is similar to git flow but made more complicated like we have a development branch and then we have a branch for every environment like staging, integration, init. We have release branches and branches for different environments like development environment, integration environment, staging environment and then everything needs to be merged everywhere, pull everything and also multiplied by the number of releases we have in parallel. So this strategy is silly because it’s assumes that we need a branch for each environment where we are deploying something.
Conclusion :
So; you should be using trunk based development if you know importance of testing automation and your coverage is so high. You should be using feature branches if you are working in small self sufficient team with small applications. If you are having open source project then you should go with forking strategy.
So; this is all about Branching Strategy. Thank you for being with me till the end. I hope this both blog will really helpful to explore about branching strategies.
Happy Learning..!!
