0

I've seen in many places, one of them here (and also in the guiding questions of GitVersion) that, when coming to determine whether or not to use GitFlow, one key consideration is whether or not I need to maintain several versions in production.

So if the answer is yes - GitFlow can fit you. What objective advantage does GitFlow have over GitHub flow regarding this scenario?

The reason I’m asking: Other than the fact the GitFlow strictly defines the naming convention of branches so we have "hotfix" branches, from a technical POV I don't see why GitHub flow doesn't allow you to assign a team of developers to branch off of the buggy version (identified by tag) while the rest are still working on the next features that will be merged to main?

Improve this question
9
  • 1
    if you did that then you have changed to gitflow
    – Ewan
    Jul 30, 2021 at 7:13
  • endoflineblog.com/follow-up-to-gitflow-considered-harmful See the “I can’t delete my release branches” section
    – jpmc26
    Jul 30, 2021 at 7:33
  • @jpmc26 That article is kind of funny. The author originally started with "I don't like Git Flow" (and IMHO for uninformed reasons), so he offered an alternative. Then he started responding to some of the criticisms, so he offered workarounds and tweaks to his strategy, which if you do all of them, makes it nearly identical to Git Flow again.
    – TTT
    Aug 13, 2021 at 14:33
  • @TTT If you had paid any attention to the article, you'd have noticed that it's not at all like Gitflow. And the core difference is obvious: OneFlow eschews the systematic permanent branches and non-fast-forward merges that Gitflow requires and that make your repository history look like a game of Guitar Hero, by limiting them to only the cases where they're absolutely necessary. If you don't have all the parallel branches being merged into each other constantly, you're not using Gitflow. OneFlow's goal is to use Git's features properly to generate a simpler history, and it does so.
    – jpmc26
    Aug 13, 2021 at 23:19
  • @jpmc26 Trust me, I paid attention. 1.) Git Flow problem: you don't need two long lived branches. One Flow Solution: just have one branch. Complaint: But then I have to find the latest tag to know what's in production? Solution: create another long lived branch called current, or name it master if you prefer. (That just went full circle back to Git Flow.) That is the exact reason master exists in Git Flow, if you choose to use it.
    – TTT
    Aug 14, 2021 at 0:11

1 Answer 1

Reset to default
4

GitHub Flow doesn't support multiple versions being supported at once. A release occurs after every commit to the main branch. GitHub Flow is designed for use in environments that are practicing Continuous Delivery or Continuous Deployment, where the commit to the main branch triggers the deployment. If you are not deploying shortly after a commit to the main branch, then GitHub Flow isn't a good fit.

On the other hand, in Git Flow, deployments happen from release branches made off of the main branch. You can then keep the release branch around for patches for as long as the version exists in production, applying the patches to all of the supported versions, using either cherry-picking or manually depending on the state of the code for each version.

In GitHub Flow, there's no reason why a team of developers can't branch off the buggy version identified by a tag. However, since GitHub Flow is designed to support only one version in production, the buggy version would always be the current head of the main branch. The developers fixing the bug and the developers working on a new feature would both be branched off of the head of the main branch and, depending on who finished first, the other group would likely want to synchronize their branch with the updates committed to main.

It's also important to note that there are at least two versions of the GitHub Flow. In the original version, changes are merged to the main branch and the main branch is deployed shortly after each merge (which may result in two merges close together being deployed together). In the newer version, the feature branch is deployed and then merged into the main branch.

My personal preference is the first version, where the main branch is deployed to production. However, there is another question here on Software Engineering Stack Exchange as well as a GitHub blog post that go into details about how the newer version works for GitHub. It seems like they have infrastructure in place to ensure the safety of deployment from feature branches to production and prevent a feature branch that is missing commits from being deployed.

Thanks to TTT for finding some of this information and pointing it out in the comments.

Improve this answer
10
  • I think you're looking at it backwards. What do you mean by "GitHub flow doesn't support.." ? You mean it doesn't fit a situation you have several versions being supported at once? That again sounds like "just because". My question is: why isn't GitHub flow ALSO suitable for a situation in which you have several versions in production? And since from a technical POV there is no reason you can't branch off of a buggy tag and fix the bug -as you stated yourself - the question arises - so why isn't GitHub flow suitable for such usecases?
    – YoavKlein
    Jul 30, 2021 at 11:54
  • 1
    @YoavKlein I'm not looking at it backwards. The creators of GitHub Flow did not need to support multiple versions in production, so they didn't create a model that supports this. GitHub Flow is well-defined and deployments happen from the main branch, so there's no opportunity to deploy other branches to other environments. The moment you deploy a branch that isn't the main branch to the production environment, you are no longer using GitHub Flow.
    – Thomas Owens ♦
    Jul 30, 2021 at 12:08
  • 1
    @YoavKlein If you read my answer, I did address that. Git Flow has release branches that can be deployed to one or more environments and there's no mapping between release branches and environments (they don't even need to be production environments). GitHub Flow does not have release branches - the only branch that can be released and deployed is the main branch and there's a 1:1 mapping between the main branch and the production environment. Understanding why the strategy was developed and what problems it was developed to solve is key to understanding when you should use it.
    – Thomas Owens ♦
    Jul 30, 2021 at 13:42
  • 1
    @TTT That seems to be the difference between the original GitHub flow and the most recent GitHub flow. I don't like the idea of pushing a random branch to production since it could be out-of-sync with stuff in the main branch. Merging and deploying shortly after merge feels safer, and was the original flow. I'd be curious what drove the change and why it was done.
    – Thomas Owens ♦
    Aug 13, 2021 at 16:52
  • 1
    Regarding the new GitHub flow design, I found a question with GitHub's answer.
    – TTT
    Aug 16, 2021 at 17:29

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.