all 3 comments

sorted by: hot top controversial new old
[–] [S] 5 points 2 years ago (1 child)

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.

  • source
  • hideshow 2 child comments
  • [–] 2 points 2 years 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.

  • source
  • parent
  • [–] 1 point 2 years ago

    As an in-depth alternative, I recommend "Patterns for Managing Source Code Branches" by Martin Fowler: https://martinfowler.com/articles/branching-patterns.html

  • source