from Hacker News

The Problem with Git Flow

by silasdb on 6/24/20, 12:00 AM with 112 comments

• by dastx on 6/24/20, 7:11 AM

  I don't quite understand why people don't keep it simple. Use short lived branches, and merge to master. Need to do a release? Master is your release. Tag the release when it's ready. Need to make a hot fix onto the current deployed version? Create a release branch from the tag, and then create a new tag and merge back to master.

  This combined with semver gets you far. I've yet to find any downsides with this approach.

• by wcarss on 6/24/20, 1:54 AM

  Trunk flow has a lot going for it. Here's a link in case others don't know of/haven't heard about it -- it starts off with a tl;dr summary: https://trunkbaseddevelopment.com/

  One of the key elements of trunk flow that I value about it is that "the software you released" is not a living stream. Because of that, it should not be tracked by a long-lived branch with commits that flow in in over time except in rare fix situations. With trunk flow and similar styles, you can always merge to master, and you can always deploy master. You do so by cutting a new branch, and in my opinion, you then build a static artifact. Next time you deploy, you cut another branch, build your artifact, and put it somewhere.

  Need to do a hotfix, but there's other work since last release that you just can't ship? Cherry-pick onto the currently-deployed release branch, not onto some long-lived production branch. There's no weird merge-backs, no strange no-op commits in a long-lived history.

  trunk-flow is also very simple. For these and other reasons, it's great.

  And, some key points about building static deployment artifacts: if you build an artifact to deploy at merge-time to master, you can avoid having your production servers download and execute code for you. You can test your exact artifact before you ever send it to production. You can reproduce your builds. Left-pad-like library unavailability issues can't hit between staging and production. Deployments to production are very fast. You can keep a few artifacts around and roll back quickly and reliably to working states (barring database stuff!). You can deploy two versions to different userbases at the same time. It's very useful. :)

• by jdlshore on 6/24/20, 3:58 AM

  Martin Fowler wrote a superb discussion of branching strategies. It's here: https://martinfowler.com/articles/branching-patterns.html

• by viraptor on 6/24/20, 5:09 AM

  I've got strong feelings about git-flow, but I think the main thing all these "generic flow" solutions are missing is: what are your project requirements?

  Some projects need release branches, some projects use continuous deployment, some projects need manual QA, etc. There is no solution that will work for everyone, so unless your flow description starts with assumptions and matching requirements, it's wrong. (for some people reading about it)

• by dragonwriter on 6/24/20, 7:15 AM

  What a clickbaity title; there's no substantial discussion of Git Flow at all; the paragraph they actually spend discussing two minor issues sounds like it was written by someone who has never done serious work in Git Flow.

  Should be titled “The sales pitch for GitLab Flow”.

• by danw1979 on 6/24/20, 7:49 AM

  > Git flow forces developers to use the develop branch rather than the master.

  No it doesn’t.

  > Another frustrating aspect is hotfix and release branches

  I beg to differ.

  I know what would be frustrating though:

  > GitLab Flow is a way to make the relationship between the code and the issue tracker more transparent. Each change to the codebase starts with an issue in the issue tracking system.

  ... tying my repo to one particular git hosting platform.

• by sn1de on 6/24/20, 5:28 AM

  I honestly thought they were finally renouncing GitLab flow as a massively misguided idea. They are both flawed. You shouldn't be using branches in your version control system to denote stages in your development process or deployment targets. It totally breaks down when you move to CICD, which should be your goal. Trunk based is the way to go. These git flow things persist because that is what the search engines puke up when people google for git branching.

• by servilio on 6/24/20, 6:07 AM

  There is a need for simplified workflows, but this sounds and looks like an exercise in brand marketing more than a good analysis on how to offer a better Git workflows.

  > Git flow forces developers to use the develop branch rather than the master. Because most tools default to using the master, there’s a significant amount of branch switching involved.

  I'd like to see this fleshed out, since whatever branch naming convention or roles you use, you will be switching the same amount.

  > Another frustrating aspect is hotfix and release branches, which are overkill for most organizations and completely unnecessary in companies practicing continuous delivery.

  Yes and no. If you don't separate master from develop, hotfix branches just work like feature branches. But if you need them separated, then...

  > Bug fixes/hot fix patches are cherry-picked from master

  Avoid doing this, use daggy fixes[1], and it will make it breeze to check that a fix was actually merged and where[2]. And if you do cherry pick, at least use "-x".

  [1] https://wiki.monotone.ca/DaggyFixes

  [2] git branch --contains <commit>

• by bredren on 6/24/20, 1:49 AM

  I am a fairly committed practitioner of git flow on multiple projects.

  The problem of not easily linking feature branch names to issues is real, though I have been solving this using:

  `[issue id]/feature-or-issue-title-abbreviated`

  And while you don’t get nice hyperlinking from the branch references on GitHub—-and it’s possible for the issue title to be out of sync with the feature branch name at times, it isn’t too bad and I don’t often need to go back and look at a feature branch.

  Perhaps projects with bigger teams this is more important and the linking / strong issue attribution to the branches is more meaningful.

  I’m less clear on the removal `develop`. It makes more sense to me to use master as this serious “released” state. And for develop to be a bit more loose.

  More importantly, I typically will run `develop` on a staging instance. So it’s pretty important to me.

  I still do testing on ‘develop’ and feature branches before they are merged. I also don’t feel like the start / finish release process is all that onerous.

  From a commercial standpoint, I’m not a huge fan of tossing GitLab into the concept name. It’s a little brand-y on something that just doesn’t need it.

• by ablanco on 6/24/20, 4:43 AM

  I don't think this is a problem with git-flow, it's more a problem of using git-flow when you don't need it.

  I use git-flow on projects that need to be installed by various different clients and there's no way to force all of them to migrate to the latest version, so you have to maintain support for older releases.

  When the software needs to be installed in a single place and you can do it with CI/CD theres no need for the git-flow complexity.

• by ramenmeal on 6/24/20, 6:15 AM

  I'm not a fan of merging master -> production for deployments. This means that what you tested in master may not be the same artifact that is deployed to prod. You're relying on people to correctly handle merge issues in git. This can become an issue if you have some complex hotfixes that have to happen.

  edit: I'd rather trunk based w/ tagging commits for releases.

• by somewhereoutth on 6/24/20, 2:38 PM

  I feel a whole lot of problems would just go away if merge was abandoned. Thus every 'merge' would require a rebase (and subsequent deletion of the merged in branch), and branches stay as branches. For example it then becomes obvious and inevitable that hotfixes must be on an independent maintenance branch (cherry picked in/out of the master if appropriate). There is no longer the proliferation of merged in feature branches - only features currently worked on (and yet to be rebased) would have a branch. There is no concept of release vs master vs dev as it is not possible to merge one into the other. Push/pull is fast forward or force rebase.

  Easy enough to write a wrapper around git to do this - I am tempted.

• by polymeris on 6/24/20, 12:47 PM

  On the topic of Git Flow and simpler & faster alternatives, last month I published a short blog post about my experience learning those alternatives exist at CircleCI[1].

  The most important learning for me was that things like Git Flow aren't free: they slow you down and make developers feel more detached and less responsible for the code that's running in prod.

  [1] https://circleci.com/blog/you-are-what-you-git-how-your-vcs-...

• by alkonaut on 6/24/20, 12:31 PM

  I immediately spot one huge issue with this

  > The production branch is essentially a monolith – a single long-running production release

  It assumes that only one version is deployed at a time, so you can't really service version1.0 after you shipped version2.0.

  Having multiple independent maintenance branches for production is critical for any branch pattern that should apply to both web software (normally single deployed version) and e.g. Desktop (normally multiple deployed versions).

  Th

• by steve_taylor on 6/24/20, 2:01 PM

  This is idiotic. Different situations call for different workflows. Working in a corporate environment with planned, infrequent releases? Use Git Flow. Doing continuous delivery instead? Use the feature branch workflow.

  This smells like GitLab trying to increase its ownership of the ecosystem.

• by tupac_speedrap on 6/24/20, 10:44 AM

  How is git flow complicated? I feel like some developers are doing shonky stuff with git branching and then blaming it on the branching strategy.

  If you used a system with less use of branches you'd just end up with dodgy code in master instead.

• by jjuel on 6/24/20, 3:04 PM

  Am I missing something or is this pretty much Gitflow with develop being named master and master named production? Maybe I don't fully understand Gitflow or we are using it like Gitlab Flow already with different names.

• by einpoklum on 6/27/20, 9:13 AM

  My problem with this suggestion is, that I tend to do history rewrites on the development branch, if I realize I've fucked something up; but I don't do that on master. So on master, broken things get fixed with a new commit; on development - sometimes, sometimes they get fixed retroactively.

  That means that you can safely "git pull" the master branch, always, into the future, but if you try to pull the development branch, you may well fail.

• by somewhereoutth on 6/24/20, 12:40 PM

  I think this sort of thing might become much more tractable if it were possible to visualize a git repo as it actually is - i.e. a directed graph of commits (occasionally with two parents - a merge commit), with moving labels (branch names) and fixed labels (tag names). Like when you buy a small shrub from the garden centre and it has a label attached to it somewhere.

  Pushes and pulls can then be visualized as two such shrubs reconciling themselves.

• by rob74 on 6/24/20, 12:47 PM

  Interesting tidbit: according to the "SEO-friendly" URL, the title should actually be "what-is-gitlab-flow" - I wonder if that was also the original title of the article, before it was changed into something more "clickbaity"?

• by pronoiac on 6/24/20, 1:29 AM

  > run all tests on all the commits

  That gave me pause; I'm used to relatively small commits, for easier review and verification, so that seemed too much. Reading the link, I think they mean, run tests on every branch on every push.

• by sebazzz on 6/24/20, 4:54 AM

  We currently use a simplified version of gitflow. Essentially we picked only the master, develop, and release branches from it. Of course we do have experimental branches but all nowhere as complicated as gitflow.

• by thisisastopsign on 6/24/20, 1:49 PM

  Sometimes I feel there should be a survey for Git methods and people vote on it. Repeat annually. Eventually we'll settle the debate

• by king_magic on 6/24/20, 2:05 PM

  I've literally never had a problem with Git Flow, nor have any developers I've worked with. It's fine.

• by WWLink on 6/24/20, 5:57 AM

  Between monoliths, this discussion, and other complaining about git I see around here, I wonder just how many of you are using subversion lol.

• by hellofunk on 6/24/20, 9:56 AM

  Trunk-based development FTW!

• by malinens on 6/24/20, 2:21 PM

  the problem is that gitlab works very bad with other git flows and they are ignoring issues about them so they force their own flow sadly...

  I still enjoy working with gitlab but this annoys me very much

• by 0x00101010 on 6/24/20, 12:14 PM

  man gitworkflows

• by renewiltord on 6/24/20, 7:15 AM

  Gonna be honest with y'all. You don't need a git workflow. Seriously, YAGNI. Deploy every `master`, no other restrictions.

  Git workflows are over-engineering.