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.
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.
