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.
4
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.
1
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
It depends on how your development team and tasks are organized. In my opinion, the model you specified would work best if:
- Each developer works on independent tasks by themselves.
- 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.