I saw around that development teams usually use source control in one of 2 schemes:

Either "Feature Branch", where each feature is developed in a new branch, or "Developer Branch", where each developer in the team has a dedicated branch for his work.

I understand the technical differences, but I don't really understand when it's better to use each scheme.

I mainly use HG, but I don't think it matters

  • 1
    You could argue that you're always using developer branches using git, hg or similair. Since locally everyone always has their own branches.
    – iveqy
    Dec 18, 2014 at 18:55

1 Answer 1


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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.