If I understand your question correctly, this seems like a case where per-feature branches are superior: Developer A is working on feature 1 and feature 2 conc

If I understand your question correctly, this seems like a case where per-feature branches are superior: Developer A is working on feature 1 and feature 2 concurrently. Developer B is working on feature 3 most of the time, but wants to make a change for feature 1 that isn't worth merging with master until feature 1 is ready. Using the per-developer branches model, that would be annoying to deal with. Using the per-feature model, its as simple as A committing to branch-1 and branch-2, and B commiting to branch-1 and branch-3. The main issue here is, if you are using Git why does it matter how each developer organizes their branches? Everyone can use whatever branching model they want on their own, then use whatever merging/rebasing strategy is agreed on into the main branch. If you absolutely must use the per-developer branching model, but want to still have per-feature branches: just use feature branches coming off your personal branch, then rebase the feature branches into your personal branch as needed before merging with the master branch.