• @[email protected]OPM
    link
    fedilink
    English
    51 year ago

    Apart from the historical value, the most important part of this article now is the “Note of reflection” added 10 years after it’s inception:

    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.

    I don’t think this work flow is relevant any more even for teams that don’t do CD, to be honest. It was a messy work flow to begin with and I haven’t seen it applied successfully in practice.

    • Oliver Lowe
      link
      fedilink
      21 year ago

      the most important part of this article now is the “Note of reflection” added 10 years after it’s inception

      Agreed; amazing to see this added. I suppose it’s admirable… but the pain that has been inflicted on the teams I’ve been part of in the meantime… ugh.

      I haven’t seen it applied successfully in practice.

      Neither.

      I could see the value, in theory, for geographically separate teams spanning many time zones juggling concurrent development efforts. But the reality for a lot of commercial software development is totally the opposite. It’s done in offices where staff are in at 9, out at 5, all working on the same features in a linear style. They’re not developing an OS kernel; they’re maintaining a CRUD app.

      For that “git-flow”, code needs to be in a state where it can have patches rebased/merged independent of one another. The codebases I’ve worked on have never been anywhere near that robust.