"No shared view of the product. Since everyone is working on a long feature branch of their own, there is no consensus view of the state of the product. Manager

"No shared view of the product. Since everyone is working on a long feature branch of their own, there is no consensus view of the state of the product. Managers can’t look at it and get a feeling for what is going on. Features get no “free” QA testing from other developers, because only the developer working on that branch will see them. It is only when everything is integrated (in a scramble, just before the release) that the true status of the product is known." This "free" QA testing is NOT free. It is in fact what branching is meant to remove. You don't want to mix your dev's development and integration work, they are completely different processes. What you need is your QA team(or your devs with their QA hats on) actively merging all "ready" branches into an "integration" branch and testing that. You need people to be able to signal "yeah, my branch is stable enough to be merged for integration testing" or "no, don't merge my broken branch that I'm still working on, you'll just waste your time". Incidentally, that's what a pull request is. The integration branch is mentioned in gitflow but not really expanded upon. I agree with the author that the way they present master/develop, there's not much benefit to develop. However, you need a branch where you're continuously integrating(cough). This is "extra work" that you need to do, but there's no way around it. You can "do it for free", essentially forcing every dev to be a QA at the worst possible time, disrupting their own workflow, or you can separate it as its own workflow. Whatever works for your team.