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