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