1

I've read the canonical article about GitFlow by Vincent Driessen, and there are 2 things I'm not sure about:

  1. In the big diagram in the beginning of the article:

enter image description here

In the line of the develop branch, we see some commits that seemed to be just committed directly to the develop branch (not merged from any feature branch). Is that possible according to the strict rules of GitFlow, or is it just inaccuracy in the diagram?

  1. In the section about "Hotfix" branches, it says that once ready, the hotfix needs to be merged back into develop. But what if the bug was found a fair amount of time and releases after that bugged release was released? Say we're already in version 5.1 and a bug was discovered in 2.5, in which case it may be completely irrelevant to merge those changes to develop.
Improve this question
2
  • Useful question; you’re certainly not the only one who wondered about this. I updated the title to give a hint on what is asked with a view to helping others find it faster. Don’t hesitate to fine tune it, if my change is not good enough.
    – Christophe
    Jul 30, 2021 at 10:15
  • This site format doesn't really work well with multiple questions asked at once. I could probably write an interesting answer to your second question, but not your first.
    – IMSoP
    Jul 30, 2021 at 12:36

1 Answer 1

Reset to default
6

My prefered explaination is : https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

  1. I don't think commits to develop are strictly forbidden. You are just supposed to use feature branches for features. If you only have a single commit in a feature branch, or you squash them, then its equivalent to committing direct to develop

  2. The assumption is that because you have just found the bug and its in your live, or a live version, you still have it in your current code base. Obviously if you have since removed the feature that contains the bug; or otherwise fixed it, you wont have anything to merge

The real question with gitflow, or any branching model is what do you do with the branches. Git allows you to branch and merge in a virtually unlimited fashion, but:

  • Do you test a feature branch before you merge to develop or test merged features on develop?
  • Do you keep release branches and let them diverge from later releases or merge them back in and only have a single 'live' release?
  • Do you merge in features but toggle them off with feature toggles until ready, or have the merge be the 'go live'
  • Do you release after every feature, or bundle up a few features into a release?
  • Do you put all your components in a single repo, or separate then out by product/application/service

These choices are left out of the branching model and are really what defines your development process rather than what you call the branches.

Improve this answer
2
  • about the second answer: So say I've found a bug that is in A live version, but that live version is not THE live version, and the client of that older version wants a fix for that bug? I don't want to merge this fix into my master since it's an older version, so how GitFlow deals with this? About the bullets you listed - I think most of these questions are not about GitFlow but rather decisions about the development process.
    – YoavKlein
    Jul 30, 2021 at 4:56
  • 1
    gitflow would tell you to merge it. But if the bug doesnt exist on the live version that would be a no change merge
    – Ewan
    Jul 30, 2021 at 7:10

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.