Git – Why Test on Release Branch Instead of Develop Branch

It comes from the CI mindset where there is integration several times a day.

There are pros and cons of both.

On our team we have abandoned the develop branch as well since we felt it provided no additional benefit but a few drawbacks. We have configured our CI software(Teamcity) to compensate for the drawbacks:

1. Enable deployment of a specific commit. In other words: We don't deploy a branch. We deploy a commit.
2. We can deploy either master or branches starting with a hotfix/ prefix.

The reason this works is because all pull request contain potentially releasable code but this doesn't mean we deploy all commits in master.

The main reason we abandoned the develop branch is because it tended to get too large and too time consuming to see what it actually contained. If we have deployed something a little prematurely we just branch off a hotfix branch and deploy that directly.

How Long should these branches kept for ?

The first answer that pops in my mind here is :

Why are you creating release branch in the first place ?

If you are aiming to be able to provide support to a version in production use then it should live as long as that version lives with your customers. (say LTS support, you could have multiple such branches, making things a tad bit more complex)

If you are separating stabilisation work from on-going new development then once the version is deployed you don't really need that branch anymore. Here this would hint at a continuous delivery pipeline. Any bugs gets their fix in the next release which would occur as frequently as possible. Some push this to considering the master branch as the stable branch deploying multiple times daily. Others will sync to their sprints and release every two to three weeks.

Should you merge it completely back into master ?

As you guess it all depends on why you adopted this branching strategy. for continuous delivery style, since the branch will never be used again then you should treat it just as you would any feature or bugfix branches, likely you would merge it back to the master and forget about it.

If however you are aiming for LTS style then you likely would not merge it back, especially if you have multiple such branches. Here you would apply the fix to all release branches and cherry pick from one of them to merge that fix back in master. In this scenario the last thing you would want to do is to treat it like any other feature branch where changes from master are pulled up into it and conflicts resolved there rather than in the master.

Without knowing more about your product life-cycle and your team's workflow it is difficult to come up with a more precise advice here.