From my experience, feature branches are strictly more general-purpose and flexible. The advantage is that feature branches allow for a developer to work on multiple branches concurrently - and even for multiple developers to be working on the same branch, if needed, without confusion ("Why is Joe
writing commits on the Bob
branch...?").
Using developer-specific branches, although it is simpler initially, can cause friction when many features are being worked on simultaneously (things like git stash
can be used to somewhat avoid this, but at the cost of lowered transparency).
And perhaps one of the more important issues is that you lose a bit of semantic information when using developer-specific branches. The line:
git merge topnav-style-change
is simple and can help to avoid mistakes (it could not, for example, be easily confused with the branch massive-refactoring
). On the other hand,
git merge joe
does not convey much by itself ("Was it Joe or Bob who was working on the style changes...?").
For these kinds of reasons, in general, I see more projects nowadays using feature branches. However, the two choices are not necessarily exclusive - they could be used together as-is, or even in some kind of hybrid mix. It really depends on the complexity and needs of your project.