9 votes

Please stop recommending Git Flow

16 comments

  1. [11]
    aphoenix
    Link
    It's late and I'm feeling blunt. It's hard to take an article seriously when it talks about Git Flow being too complicated - it is not complicated on its face, or on any other part. It makes a ton...

    It's late and I'm feeling blunt.

    It's hard to take an article seriously when it talks about Git Flow being too complicated - it is not complicated on its face, or on any other part. It makes a ton of sense and is really easy and intuitive; it took me 15 minutes to explain it to our non-technical client liaison, and only 30 minutes to explain it to our junior devs. Since the alternative is tagging, it's important to note that tags are inherently a bit less understandable, in general, than branches; you need to know how branches work to use git, but you don't need to know how tags work.

    It's also hard to take it seriously when it takes one of the actual strengths of Git Flow (disentangling / wrangling commits for continuous integration) and tries to frame it as a drawback somehow. Commits to master trigger automatic deployment. It actually doesn't get much easier than that, and I'm perplexed as to how someone can actually bring this up as a point of contention for Git Flow. Well, I guess it could get a bit more complicated; you could have commits to develop automatically deploy to your stage environment. That's not really that complicated.

    In my experience the people who are against Git Flow tend to cite the desire to have a "healthy commit tree". I've never understood why some people have their heads so far up their own asses about having a nice looking tree of commits. The graphs that they are looking for are typically what you would describe as "a lie". Your git commit history should be the history of the work that you've actually done. If you spend your time making the connecting points of the graph that shows how work was integrated look pretty, then that is a waste of time. It's better that it actually shows the things that happened, so that if you need to look at why something ended up in a particular state, you can identify it.

    I'm not saying that there is no utility in a clean looking tree, but far too many people spend far too much time sculpting their git log into something that it wasn't so that they foster this lie about how the development happened.

    Git Flow, like almost every other branching model, has strengths and drawbacks. Saying "Stop recommending Git Flow" is as stupid as saying "stop recommending JavaScript". Sometimes that's actually the right tool for the job. This guy's inability to wend their way through a drawing because they prefer tags and rebasing doesn't mean that Git Flow is necessarily bad or wrong. I'm actually getting pretty sick of articles like this, where someone makes a proclamation about how everything should be based on their very limited understanding of one very small section of the industry.

    Go ahead. Use Git Flow if you like it. It's not harmful; it can be beautiful when you implement it correctly. Note that there is a high likelihood that the model isn't right for your use case - it's not necessarily great for a single developer working on something on their own, or for a startup with 50 people trying to push out something new every day. But if you have a mid size tech company that works on a dozen different projects a year, it might be worthwhile to check it out!

    13 votes
    1. [10]
      reese
      Link Parent
      I used an adaptation of GitLab Flow for a long time. It's a similar branching strategy addressing common criticisms of Git Flow. Worked great; made releasing a dream. Having some kind of branching...

      I used an adaptation of GitLab Flow for a long time. It's a similar branching strategy addressing common criticisms of Git Flow. Worked great; made releasing a dream. Having some kind of branching strategy, any kind of branching strategy, I don't really care which, is probably ideal for a large team maintaining a fleet of services. A sufficiently complex open source project with a big enough core team can benefit as well. Even the author of the linked article admits the gist of what I'm saying, reluctantly, and then concludes he can't know what the reader's needs are. Heh. Actually, you can just dismiss the entire article when he says at the onset:

      I’ll claim it as a truism that not all strategies work in all situations, with all people, in all contexts, and I apply that same logic to this branching model.

      Got the reincarnation of Plato over here.

      Aside: Maybe I should start using the ignore feature more, but so many of the blog posts submitted to Tildes are nothing more than artificial controversy manufactured by attention seekers with chips on their shoulder. The Cloud, wahhhahh! Microservices, waahhhhh! Monorepos, waahhhahhhhahhh! It's like a baby that won't stop crying and doesn't know why. Does baby need a bottle? Look, there's a load of popular practices I consider to be anti-patterns, but I'm not going around and shitting on anyone's front porch. The reality is that we choose our teams and we choose how we build and release our own software.

      1 vote
      1. [9]
        cfabbro
        (edited )
        Link Parent
        I get what you're saying in your aside, since some of the articles submitted here definitely do seem to be somewhat hyperbolic/contrarian at times and designed to intentionally illicit...

        I get what you're saying in your aside, since some of the articles submitted here definitely do seem to be somewhat hyperbolic/contrarian at times and designed to intentionally illicit controversy, which I am also not a fan of... but even so, your rant comes across as a very personal attack against the users submitting them, and is pretty mean-spirited, which is rather inappropriate here, IMO.

        6 votes
        1. [5]
          aphoenix
          Link Parent
          So, generally, <3 you, <3 your points of view. I agree with @reese here to some degree. On Tildes, and on other platforms, I have seen an increased number of articles from authors who are writing...

          So, generally, <3 you, <3 your points of view.

          I agree with @reese here to some degree. On Tildes, and on other platforms, I have seen an increased number of articles from authors who are writing things in a particular way to create controversy, which draws attention, which creates page views. This article is an excellent example of it; I'll allow that there are good points in the article, but generally it's a bad article. I would say that to the author's face if he were right in front of me. He should stop writing hit pieces that state things in terms of absolutes when there isn't an absolute answer to which branching strategy is the best (or really even which one is good, which is really a team by team basis sort of thing). In general, I think we should stop giving views or time to articles like this. I would say the same to the person who submitted the post (I guess I have: @SUD0). I am absolutely not saying this as an attack on the submitter, who is great, but instead as someone who generally wants to see fewer articles like this because I think these are actually detrimental; nobody who reads this is going to become a better programmer, which I think should be the desire for things that are linked to from here.

          I would personally have stopped short of saying "Does baby need a bottle", but that's only because I can't see myself actually saying that. I think that the article itself is very juvenile, and is the sort of thing that an intermediate developer might write to try to sound important.

          8 votes
          1. [2]
            reese
            Link Parent
            Yeah, on the baby analogy I was being an asshole. I shouldn't have done that, it itself was juvenile, and I can come up with more productive ways to illustrate my points. Stands in the corner. And...

            Yeah, on the baby analogy I was being an asshole. I shouldn't have done that, it itself was juvenile, and I can come up with more productive ways to illustrate my points. Stands in the corner. And just to be clear, I was not attacking the submitter, but I was attempting to call into question the utility of topics like this and the intent of the author. People submit things here they themselves disagree with all the time, and that's part of what makes for good discussion. But the article itself is baiting controversy.

            7 votes
            1. cfabbro
              (edited )
              Link Parent
              Just to be clear, I absolutely do agree with you (and @aphoenix) there. Sorry if I came across as trying to incite others to attack you, as that was genuinely not my intent. I perhaps got a bit...

              But the article itself is baiting controversy.

              Just to be clear, I absolutely do agree with you (and @aphoenix) there.

              Sorry if I came across as trying to incite others to attack you, as that was genuinely not my intent. I perhaps got a bit triggered here myself and went overboard in my criticism of your choice of words... so, I'm sorry about that too. Perhaps I should have started this whole thing as a PM? Anyways, 💖🕊️

              1 vote
          2. [2]
            SUD0
            Link Parent
            Good point. I'll keep this in the back of my head when deciding on whether I should post something here. I didn't have any ill motives for posting this. I thought it was interesting that this...

            .... nobody who reads this is going to become a better programmer, which I think should be the desire for things that are linked to from here.

            Good point. I'll keep this in the back of my head when deciding on whether I should post something here. I didn't have any ill motives for posting this. I thought it was interesting that this author had such a strong opinion against a branching strategy that I was taught in school. Wanted to hear what other people thought about it.

            6 votes
            1. aphoenix
              Link Parent
              I think there's actually a place for discussion like that, and Tildes is actually a great way to set up for this sort of discussion, so I absolutely do not want to discourage you from posting. I...

              I think there's actually a place for discussion like that, and Tildes is actually a great way to set up for this sort of discussion, so I absolutely do not want to discourage you from posting.

              I think that just the context of "I thought it was interesting that this author had such a strong opinion against a branching strategy that I was taught in school. Wanted to hear what other people thought about it." sets up such an interesting post! But I got caught up in disliking the blog post itself, and we ended up in this meta-discussion about if articles like this should even exist instead of the actual interesting part which is branching strategies!

              Turns out that the actual important part of "branching strategies" is just "have a branching strategy". That's about 90% of the work right there; set up a system whereby you can get working software. The important thing in all software development is to develop software, so all decisions should be made through the lens of "how does my team function and what sort of strategy will enable them to actually get code out the door?"

              It's a great question, and one that has a lot of different ways to answer, and touches just about all aspects of actually writing software, and there's no "right answer". While I think that this article is waaaaay off base because there's lots of great things about Git Flow, I don't actually think that Git Flow is something everybody should consider, because that's just as wrong. Git Flow is good for some situations, and not good in others. The same is true in most of the debates raging online: docker is great for some situations and not good in others. AWS is great in some situations and not good in others. Vim is great in all situations. Monorepos are great in some situations and not good in others. This list could go on, and could apply to things like operating systems, IDEs, programming languages, general architectural choices, javascript libraries, game development platforms... in almost every case there's no "right" answer, there's just answers that are varying degrees of goodness depending on what you're trying to do.

              I would love to write an article about the pros and cons of a lot of different things, but it would mostly be about the journey to understanding that "this thing I don't like" is actually valid and useful for a lot of people. That journey is part of becoming a "senior developer". The other part is knowing how to approach problems and being able to make the decision that Git Flow is worthwhile for your team or not. Blanket statements of how things should be are not the mark of a good senior developer; they're the mark of someone who, as I bluntly said last night, has their head up their own ass too far.

              5 votes
        2. [3]
          reese
          Link Parent
          I grant you that taking the least charitable view of what I said could come across as a rant or an attack. To put what I said another way, I think we should ask ourselves whether posting topics to...

          I grant you that taking the least charitable view of what I said could come across as a rant or an attack. To put what I said another way, I think we should ask ourselves whether posting topics to stir controversy about non-controversial issues is a maladaptive behavior. That's the point I'm trying to drive home. The idea that we should tolerate something that is of seriously questionable intent comes back to the paradox of tolerance. But next time, I'll leave it alone.

          2 votes
          1. [2]
            cfabbro
            (edited )
            Link Parent
            Even with the most charitable interpretation it still comes across as a personal attack against the authors, at the very least, but regardless of that, it's still incredibly condescending and mean...

            Even with the most charitable interpretation it still comes across as a personal attack against the authors, at the very least, but regardless of that, it's still incredibly condescending and mean spirited IMO.

            And the paradox of tolerance is about tolerating messages (like calls to genocide) that could potentially lead to the tolerant being destroyed, and tolerance with them. How does posting opinions on computer science topics that you don't agree with the conclusions of, hyperbolic/contrarian/controversial or not, have anything to do with that?

            I understand you're frustrated seeing these sorts of submissions pop up over and over (so am I, TBH)... but I still don't think that warrants making it so personal and being so mean about it. Imagine if the author (or submitter) was physically right in front of you... would you have dared to say all that to their face? I suspect not, as that would be incredibly rude and might even result in a serious altercation, so why is saying it online suddenly okay?

            4 votes
            1. reese
              (edited )
              Link Parent
              I find the article inherently condescending and mean-spirited. It's a personal attack on people who simply use a strategy the author disagrees with. The proof is in the title itself. The idea that...

              I find the article inherently condescending and mean-spirited. It's a personal attack on people who simply use a strategy the author disagrees with. The proof is in the title itself. The idea that we tolerate topics like this here is wearing thin on me, personally. I don't care if they're about software engineering or mowing lawns. We tolerate an arguably intolerable topic, but we can't tolerate a comment intolerant of it? Are you serious right now?

              I don't see how the paradox of tolerance can't be applicable here, since it's a general salve for maintaining healthy communities. If an analogy to the paradox is more appropriate, then please take that to be my meaning.

              And I'm not jarring back and forth with you about a comment that would otherwise be innocuous common sense, even IRL, without the implied call to dogpile me for it. Again, I'll try to leave topics like this alone. Although if I exercise such refrain, it would be nice if refrain were exercised when submitting topics like this to begin with.

              2 votes
  2. [2]
    vivaria
    Link
    A side note I'm not sure I saw mentioned anywhere... The author of the original article just added a note on March 5th, 2020 (today). I'm assuming it's in response to the publicity from the OP...

    A side note I'm not sure I saw mentioned anywhere...

    The author of the original article just added a note on March 5th, 2020 (today). I'm assuming it's in response to the publicity from the OP link?

    https://nvie.com/posts/a-successful-git-branching-model/

    Note of reflection (March 5, 2020)

    This model was conceived in 2010, now more than 10 years ago, and not very long after Git itself came into being. In those 10 years, git-flow (the branching model laid out in this article) has become hugely popular in many a software team to the point where people have started treating it like a standard of sorts — but unfortunately also as a dogma or panacea.

    During those 10 years, Git itself has taken the world by a storm, and the most popular type of software that is being developed with Git is shifting more towards web apps — at least in my filter bubble. Web apps are typically continuously delivered, not rolled back, and you don't have to support multiple versions of the software running in the wild.

    This is not the class of software that I had in mind when I wrote the blog post 10 years ago. If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow (like GitHub flow) instead of trying to shoehorn git-flow into your team.

    If, however, you are building software that is explicitly versioned, or if you need to support multiple versions of your software in the wild, then git-flow may still be as good of a fit to your team as it has been to people in the last 10 years. In that case, please read on.

    To conclude, always remember that panaceas don't exist. Consider your own context. Don't be hating. Decide for yourself.

    Tagging @aphoenix due to the mention of CI being a strength...

    7 votes
    1. aphoenix
      Link Parent
      Well... if the guy who wrote it himself feels like this is a drawback, then I guess I stand corrected, but I have found it very simple to integrate continuous delivery into our git flow. About 70%...

      Well... if the guy who wrote it himself feels like this is a drawback, then I guess I stand corrected, but I have found it very simple to integrate continuous delivery into our git flow. About 70% of our work is custom web applications and about 30% is custom web sites (usually using WordPress), and we use a slightly modified Git Flow (we don't avoid fast-forwards).

      Our CI / CD for applications looks like this:

      • commits to develop trigger a build to the dev environment
      • commits to any release branch trigger a build to the staging environment
      • commits to master trigger a build to the production environment

      We use pipelines to manage those builds and deployments.

      Our CI / CD for web sites looks like this:

      • commits to any release branch trigger a deployment to the staging environment if that exists
      • commits to master trigger a deployment to the production environment

      My shop is a bitbucket / JIRA shop, and we deploy to AWS. It did not take a significant amount of time to get these pipelines working, and it saves us a ton of time, and it really works well with our branching model, especially since bitbucket has support for our branching conventions "out of the box" which is great (ie - you can't PR a feature branch into master, a junior dev can't merge release into master etc).

      5 votes
  3. [2]
    ffmike
    Link
    It's hard for me to believe that there are a significant number of development teams where "choice of branching model" is really the largest unaddressed source of potential quality or speed...

    It's hard for me to believe that there are a significant number of development teams where "choice of branching model" is really the largest unaddressed source of potential quality or speed improvements. I've worked with a bunch of different branching models and source code control software over the years, and as long as the SCM doesn't actually lose things (hopefully no one else ever had to depend on VIsual SourceSnakes), it doesn't seem to make nearly as much difference as things like developers actually talking to one another.

    6 votes
    1. aphoenix
      Link Parent
      I kind of touched on it in another comment here, but some developers lose sight of the fact that all these processes are just things that people put in place to enable themselves to write and...

      I kind of touched on it in another comment here, but some developers lose sight of the fact that all these processes are just things that people put in place to enable themselves to write and release software. Some people get off in the weeds, and then they start to get really worried about the process, and ensuring that the process is beautiful. Processes don't have to be beautiful, they have to be unobtrusive.

      Git Flow for example, is really unobtrusive if approached correctly; I use it to abstract away "how does code get deployed" from the other developers. For them, Git Flow looks like this:

      • I work off develop
      • I write features called feature/JIRAKEY-9/feature-name and I make pull requests
      • aphoenix talks to me extensively about my code and we revise until his head doesn't a-splode
      • it gets accepted

      That's it. Branch of develop, do work. Make a merge request on your branch when it's done. It's the easiest way to do things for them.

      We also use it to abstract away development from the client liaison team. They only have to watch for release branches, and then read the changelog to see what's going out the door. Perfect! For them Git Flow looks like this:

      • a whole bunch of coding bullshit is happening over there in those rooms
      • a release branch appears! It details all the things getting launched, and the stories that they relate to in a Changelog! It's on the staging site right now, and I can go look at it
      • It got merged, so in half an hour it will be on the live site!

      For me as the technical lead, it's a great system - the people involved only need to look at the stuff that is relevant to them, and I don't have to try to explain tags to a non-technical person. Branches they get, but tags are not understandable at all.

      5 votes
  4. GoingMerry
    Link
    It’s hard to buy into this article’s argument without contrasting a different approach. Sone people I know are using a subversion-ish trunk model which makes liberal use of rebasing.

    It’s hard to buy into this article’s argument without contrasting a different approach.

    Sone people I know are using a subversion-ish trunk model which makes liberal use of rebasing.

    1 vote