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: 
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.
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.