Is it considered a good practice to have a remote branch for each individual developer in the project?

We're using Git with the following branches:

  • master
  • release
  • develop

If each developer had their own branch, they could push code into their branches and others could merge these changes into their own branches.

  • 1
    Reminds of me Accurev workspaces, except not tied to a particular machine's MAC address. I like it.
    – Brandon
    Commented Feb 28, 2013 at 13:21
  • possible duplicate of To branch or not to branch?
    – gnat
    Commented Feb 28, 2013 at 13:55
  • 1
    Why nat have a unique branch for each new feature being added? Commented Feb 28, 2013 at 15:28
  • @Loki Yeah.. its a good idea..
    – balanv
    Commented Mar 1, 2013 at 5:16

5 Answers 5


No! It is a good practice to have a remote branch namespace for each developer.

A single branch is often not enough, so the developer would either end up rewinding it a lot or it wouldn't be helpful much. You rather want to say that a developer can push whatever they want under their.name/. They can use it for publishing preview versions for others, giving version for somebody else to test or even for somebody else to integrate.

You can use this also for giving branches to integrator or you can use task-based names. The task-based names are usually easier to track for the integrator, but make developers think more about the naming and people don't like thinking. I don't know which will work better in practice; might even depend on the particular team.

  • Does anyone know of anywhere there's more discussion of $USER/branchname branches? Is there a name for this practice? (My google fu is failing me -- "git developer namespace" keeps coming up with git namespaces, a totally different thing.)
    – stevegt
    Commented Mar 14, 2021 at 17:18

I probably wouldn't give each developer a branch on the central server unless you have some sort of github-style infrastructure that allows them to create and destroy the branches themselves and clearly document what they are for. Some developers will need more than one branch and some won't need any at all, but you're creating clutter for everyone to sort through and administrative overhead for yourself.

I would encourage instead the kind of organic sharing git excels at. It's very easy to make a bare clone on your own machine, and make that folder a read-only SMB share for others to pull from. In fact, it would surprise me very much if several of your developers are not already doing this.

  • 1
    By default everybody can always create a branch. Github allows creating whole repositories, but that is overkill in this case.
    – Jan Hudec
    Commented Feb 28, 2013 at 14:04

It depends on how your development team and tasks are organized. In my opinion, the model you specified would work best if:

  1. Each developer works on independent tasks by themselves.
  2. All developers are contributing to the same task.

Where this might not work well is if you have concurrent feature projects in development and they each have multiple developers working on them.


Giving each developer their own branch can be helpful if they are all working on different things that may touch the same files. It can help prevent stepping on each others toes, but it will require every one to merge often and be responsible when managing conflicts. This is what is done in my office and it works pretty well apart from the rare day you have to manually merge half the files you edited.

If you have multiple developers working on the same feature its probably better to create branches based on the feature in development rather than the developer.


If you're working with Git, you should try out Pull Requests.

In summary, you first merge the master branch into your current working branch. Any merge conflicts will be in your local branch. This is nice because your master branch is never broken. If you really screw up, you have you local commit that you can revert to.

Once you finish the merge, you ask someone else on the team to review and merge your branch into the master branch. Never merge your own! So long as no one sneaked in and did another Pull Request, you're guaranteed to merge successfully. Since everyone is aware of the Pull Request, you shouldn't have multiple people merging into master at the same time anyway.

Once you get used to this process, you should try to merge as often as possible - sort of a poor man's continuous integration. The less time between conflicts the better. You'll identify when two people are duplicating effort and they can team up. Some places will merge every time they complete a requirement, which could be every couple hours. I recommend merging at least once a week; otherwise you need to break your tasks out better.

I typically create one branch per task. Git is nice because it distinguishes between local commits and pushes. This provides some of the benefit of each person having their own branch without all of the complexity.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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