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