The short answer: Yes, branches for bug fixes that are going into a planned upcoming release should be in feature branches. How you name feature branches or these branches for bug fixes is up to you and your team's standards, but they should be treated identically if you are following Gitflow.
Bart van Ingen Schenau's comment brings up a good point.
Gitflow has five branch types: master
, develop
, hotfix branches (prefixed with hotfix-
), release branches (prefixed with release-
, and feature branches. The master
and develop
branches are long-running branches and you do not commit directly into them. The release-
branches are made to draw a line for a particular release and then support bug fixes between the identification of the next version and the release. The hotfix-
branches are specifically for critical, out-of-cycle releases into production. The feature-
branches are for development of individual features for some future release.
Coming from environments where PRs are used and aside from an individual developer committing to a feature branch, nothing should be committed directly into master
, develop
, or a release branch. This ensures that every change is code reviewed, along with ensuring appropriate test coverage and passing tests in a CI environment before changes go in. I would be opposed to any commits directly into one of these branches, although it appears that Gitflow by itself doesn't have any problems with committing pre-release bug fixes or changes directly into the release branch and then pulling them into development and then feature branches.
In your particular case, a release-
branch isn't an appropriate place. The software has already been released and is in master
. Once a release is merged into master and tagged there, the release branch for that particular release has outlived its purpose and doesn't necessarily need to exist anymore. If you're active in cleaning up your branches (which I think that everyone should be), then this isn't even an option.
If your fix isn't critical, then a hotfix branch doesn't seem to fit either. The purpose of a hotfix branch is to let someone get critical changes into production very quickly without interfering with ongoing development. Using these should be the exception rather than the norm for a development team. In general, critical hotfixes should be an exceptional case.
The only thing left is a feature branch. Note that the section of the page linked to in the question about feature branches even says that feature branches are "sometimes called topic branches". If your change is targeting any upcoming release and doesn't meet the criteria for a hotfix, it should be in one of these branches.
feature-*
branches? Can a fix on an erroneous behavior be seen as a feature?master
,develop
,release-*
orhotfix-*
is a feature branch, so you can use any prefix you like and use a different prefix for bugs. Also, what is the difference between erroneous behaviour that works as specified and erroneous behaviour that deviates from the specification? In both cases it is erroneous behaviour, but only the last one is a bug.