Version Control – Separate Branch for Fixing Bugs During Testing Phase?

branchingdevelopment-processgittestingversion control

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.

Best Answer

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.

Related Topic