Does it make sense to create a branch for every developer?

Question

I've used Git only for sole projects. Now I want to continue working on a project with two other developers.

Would it cause problems if one developer wants to commit changes but another commit was created by another developer? Therefore would it make sense to create one branch for each of us?

Solution 1

Git, like most version control systems, is eminently well suited for use by multiple developers. Indeed, it is one of the main points of a version control system.

There is no need to create a branch per user. I would even go so far as to say that it would be counterproductive. If you are working on the same feature, you will probably want to get each other's changes, by pulling and merging. Creating branches per user is redundant and will complicate things unnecessarily.

The commit situation you describe is not problematic. If another user has created a new commit on the same branch as you, you will be stopped if you try to push. Instead you will first have to pull down the other user's commit and merge (or rebase) your work with those changes. This is the standard behavior of git pull.

Normal practice is to create branches based mainly on features. If you want guidance on branching, this is a popular strategy.

Solution 2

We used to do that in a place where I worked. Each of us had at least one personal branch - I actually created a branch for every task I had to do.

When we were done, we would do pull requests to the main branch. If someone has merged into the main branch code that conflicts with your changes, you have to do the conflict resolution just as you would with any other source control platform (like Tortoise, Mercurial etc.), but it's no big deal if your devs know what they're doing.

IMO this is the best way to conduct development in a team. You can always test in your own personal environment, quickly swicthing code from each branch as needed. The pull request system also makes peer review so much simpler, since everybody can collaborate and write comments on the relevant lines directly in the github diff pages.

Comments

[user229044]

You have one branch for each of you, unless you're all working on the same machine. When you clone your repo, you get your own set of branches, which happen to be named the same as everybody else's branches, but they're still your own branch.

[danijar]

@meagar Sounds interesting, could you please elaborate on this?

[user229044]

Every cloned instance of the repository is a fully self-contained thing. You're free to do whatever you want with your branch, you won't step on anybody else's toes until you try to push. When you push and pull, you're performing a merge of your local branch with the remote branch (or vice versa) setup as the "tracking" branch. This is identical to merging any two branches on your local machine; in fact, git pull is really just a fetch, followed by a merge. For the sake of simplicity, git push restricts merges to fast-forward merges, as you can't effectively resolve remote conflicts.

[user229044]

The point is, whether you each are working on master or whatever branch, it's your branch. Through pushes and pulls, you're merging your independent master branches into each other, and this is indistinguishable from merging local branches together. The idea of making branches with new names for each user is antithetical to Git; Git already makes separate branches for each clone, it's absolutely fundamental to how Git works.

[danijar]

@meagar Thanks a lot, made it much clearer!

[Geeky Guy]

It depends on how your work is divided. At a place I worked, we would never have two people coding on the same feature at the same time. If you do have multiple devs working on the same feature, though, I completely agree with you.

[user229044]

You still shouldn't just create separate branches per person; it should be features that drive the creation of branches. Each person should have as many branches as they have features in active development.

[Heath N]

In my opinion this answer is wrong. You should not have two devs on the same branch. What if someone squashes a bunch of commits and force pushes? If the feature warrants two developers you should figure out exactly what scope each dev is working on and have a branch for each feature. Then you can have an additional branch off master (or a milestone, etc.) and you merge those feature branches in. This will allow resolving of merge conflicts and proper testing of integrated branches before merging to master and going through a deploy process.