14

In the, commonly referred to as, Git-flow model hotfixes go in their specific hotfix-* branch and small integration fixes right before release go in the release-* branch. General bugfixes from the previous version does not seem to have a place.

Where should they appear? Should they be in their own bug-* branch branching off of develop (just like feature branches)?

  • 3
    Why would a non-critical bug in released code be different from a small feature to produce different behaviour than what the application currently does? – Bart van Ingen Schenau Jan 14 '16 at 7:59
  • @BartvanIngenSchenau Are you recommending them to be feature-* branches? Can a fix on an erroneous behavior be seen as a feature? – Shoe Jan 14 '16 at 9:09
  • 1
    @Shoe I think what Bart means is that you you should treat them as features, not necessarily using the same branch prefix. – Darkhogg Jan 14 '16 at 9:44
  • 3
    @Shoe: in git-flow, any branch except master, develop, release-* or hotfix-* 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. – Bart van Ingen Schenau Jan 14 '16 at 11:44
9

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.

  • We agree that there should be no direct commits to master, develop or release branches. But what should be the PR flow when you find a bug in release branch and it needs to be fixed in both, release and develop branches. This has it's own challenges if your entire release branch is not yet ready to be merged in develop but the bug fix should be done at both the places.. If you want I can post a new question for this. – Sap Aug 31 '19 at 8:19
  • @Sap A new question would be good, but if you post it, please explain why the fix is so critical that it needs to be merged into both - that seems to imply there was a critical issue not found before it was introduced into develop, not found between the time it was introduced and the creation of the release branch, and/or that your release branch exists for a long time. Simply, though, I believe the only choice is a cherry-pick (I'd suggest a fix and pull request into the release branch, merge into the release branch, and cherry-pick into develop via a pull request). – Thomas Owens Aug 31 '19 at 10:03
4

If its a single commit then just make a well identified commit and push it on top of the development branch, else create a feature branch.

There is also a comment from the git-flow author saying exactly what you are asking: Missing bugfix branches #24

  • Thanks, that link you shared cleared this up for me. – arcseldon Jan 8 at 14:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.