Do we need a separated branch for fixing bugs raised during the testing phase?

Question

Before release a new version of the software, which is a web application, my company creates a release branch. The QA team tests that branch and reports some issues. Should developers commit the fixing code to that release branch or a new bugfix branch that is merged to the release branch later?

For more details, my company currently use a modify version of gitflow model. We release new version every two week. feature branches are not merged to the dev branch but to the release branch at the beginning of the release process. Developers commit their fixing code to the release branch to fix issues raised by QA team and these code sometimes introduce new more issues. That is the reason why I think we should have another bugfix branch.

The bugfix branch collects all fixes for bugs that are raised from testing the release branch. After all bugs are fixed, the bugfix branch is merged to the release one and the QA team start testing the release branch another time. The release branch can be tested several times until there is no bug to fix.

Answer 1

If I got you right, you have the following issue:

• before the new version is deployed, your release branch is currently the only one collecting all fixes. A developer who wants to add a new fix (especially a fix to an issue which was caused by a previous fix), cannot test test this reliably in a development branch, because, at that point in time, the fixes made before are not integrated back into the development lines.
• so currently the only way for your team to fix those issues is to check out the current release branch, add the new fix there, test it locally, and then commit it to the release branch. Of course, this should be properly communicated to your QA team, but even then, there might be a risk of interfering with the current QA work.

Introducing an additional bugfix branch will allow you to defer the immediate delivering of fixes to the QA team. This has pros and cons. On the pro side,

• it allows your devs to test the integrated fixes not just locally before they go to QA
• it allows your team to merge the fixes into "release" and deliver them to QA at a better controlled point in time, which might reduce the perception of your web app beeing a "moving target". You might collect some fixes, and the QA team gets every two days a new "bundle" of fixes, can test it.

On the con side,

• you have to manage this additional branch and when the changes there go into "release", which means additional merge steps
• the QA team does not get the fixes immediately when they are done.

Note, however, even when not using a "bugfix" branch, the QA team does not necessarily get pushed fixes immediately into their local copy. If they want every two days a new "bundle" of fixes, they just have wait two days until they update their local copy of "release" to get the fixes. The difference is: with a bugfix branch, you can keep it under better control of the devs, with a release branch only, the control is probably more at the QA side.

Compare those pros and cons, and decide for yourself which of those two approaches will work better for your team.

Answer 2

Gitflow suggests you commit directly to the release branch

only bug fixes, documentation generation, and other release-oriented tasks should go in this [the release] branch

However, if you have multiple developers working on a release branch it makes sense for them to make 'release feature branches'

If you are in this position though, where you are doing a lot of work on release branches, perhaps you should be asking yourself if the development branch was finished in the first place. In most places ive worked, we have done QA on the dev branch, BEFORE creating a release or moving on to the next set of features.

Answer 3

There are two types of branches, shared branches and own branches. In this case, release branch is a shared branch till the release. It's important to keep the state of shared branches clean as many people depends on it. Also creating a new branch gives you the flexibility to independently develop, test and release. Even you can decide to throw away and start over.

In the case mentioned above, fix the bugs, test it and merge to release branch once it's good to go. Hope this helps.

Link: https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

--Update--

It depends on your test strategy to incrementally add fixes to release branch or add everything under one branch and release them. A single big branch could be tougher to manage as git is not very friendly with reversing the commits and changes. Git doesn't come with any branching strategy or workflows. It's up to us to choose what works for us and many big companies have published some workflows. In most of the cases, I prefer to work with git-flow or GitHub workflow.