In this post I present a Git branching strategy for developing and releasing software as I’ve used it in many of my projects, and which has turned out to be very successful.
  • @canpolat@programming.devOPMEnglish
    5•1 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
      2•1 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.