7

In order to have make sure all code eventually goes through pull request code review, we've started creating branches for features and bug branches off of develop following the git-flow style.

The only problem is that once a bug is found in a release branch, we often have to make a branch off of the release branch in order to do a pull request back to the release branch. But there doesn't seem to be an obvious git-flow process for handling branches off of the release branch when bug fixing a release branch.

What is the git-flow process for fixing release branch bugs and code review?

Are you supposed to fix the bug in develop and create a new release branch? Is branching off of a release branch still valid git-flow? What's the best way to handle pull request code reviews on release branch bug fixes?

Improve this question
2
  • 2
    Why is this case not just a classic git flow hotfix?
    – Philip Kendall
    Jul 4, 2017 at 20:50
  • @PhilipKendall - ok, say you're creating a release branch for QA before its released on production, so that regular development can continue on the develop branch. If the new release branches fails QA for some minor bug or whatever, it seems like there's no point to a hotfix because the release branch is not yet in prod. Or does that matter? do you always hotfix a release branch even if its not yet 'released' into production?
    – Mark Rogers
    Jul 4, 2017 at 21:48

1 Answer 1

Reset to default
10

From your update you're asking about a release that has not been deployed to prod. I'm assuming that means that you haven't merged to master or tagged the commit yet.

In git-flow, you would fix any bugs directly on the release branch. See the diagram below:

enter image description here

The git-flow docs I've read say explicitly

any problems are fixed directly in the release branch

I think the rationale is that these bugs should be small things that relate to the release, and it will improve your release test cycle by avoiding bug-fix branches. While the rationale is sound, I believe it's better to make sure the codebase is protected, and code review processes should not be subverted because a release needs to go out the door. Since you have a code review policy, I would recommend doing exactly what you're already doing. Create a bug-fix feature branch off your release branch, commit to the bug-fix branch, and submit a PR from bug-fix branch to release branch--regardless of what the docs say. After all, the branch strategy should be tailored to your needs, not the other way around.

Improve this answer
4
  • Thanks for the response. This is how I read git-flow too, but the problem with this approach is that there isn't a way to do pull requests from a fix branch to the release branch. How do you handle pull request review when fixing the release branch? or is pull request branching and review skipped if one is following pure git-flow?
    – Mark Rogers
    Jul 5, 2017 at 2:36
  • 3
    "there isn't a way to do pull requests from a fix branch to the release branch" how so? Git lets you merge any branch into any branch, and most Git PR systems have the ability to choose which branch to merge into when creating a PR. "How do you handle pull request review when fixing the release branch?" the same way that you described in your question. create a branch off release, and pr back into release branch. But AFAIK this isn't pure git-flow process. "pull request branching and review skipped if one is following pure git-flow?" yes that's my interpretation of pure git-flow.
    – Samuel
    Jul 5, 2017 at 2:56
  • Ah ok, just standard branches and pull requests, there's no 'git-flow' naming style or anything.
    – Mark Rogers
    Jul 5, 2017 at 3:01
  • 3
    Note that git-flow doesn't even address pull requests and code reviews. It would look exactly the same from a commit history perspective whether you branch off release and merge to release with a fast-forward merge or if you made the commit directly in the release branch.
    – Samuel
    Jul 5, 2017 at 3:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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