A friend of mine asked me the following questions:
- Are you working in different branches?
- Are you working in the same project as other developers at the same time?
As this is a topic of much debate at most offices around the world, I’m writing my own advice here. As I work almost exclusively in Visual Studio, my experience and advice is limited to that environment, and to relatively small teams.
Here’s my rule:
Try to avoid branching at all times!
Branching always costs valuable time. It takes time merging. It takes time resolving conflicts or a bad merge. It takes time explaining how it works and what features should be implemented on what branches. It takes time keeping track of your branches.
Here’s the workflow I prefer, which avoids almost all conflicts:
- Write a little piece of functionality.
- If it works and builds, check it in.
- If you know your affecting other developers, be sure to communicate this to them. Then check it in.
- Make sure your team gets the latest source after you added a conflicting change (I’m looking at you code first migrations!).
I almost never encounter any problems using this workflow. It’s great. Even when working with more developers in one project, you shouldn’t encounter much trouble.
That said, there are 2 scenario’s when I do use branching:
- Feature Reviews
When there’s a new or junior developer, I always let them work on their own branch first to implement a feature. When they are done, they create a pull request in VSTS so we can review their work together. We can discuss the code and make changes if required. - Production Releases
Once you’ve got a version in production, you have to be able to provide hotfixes for it. I do this by creating a branch for that release. When there is a critical bug, it can be fixed on that branch. If applicable the fix can be merged back into the main branch. Creating a branch for each release you need to support and developing further on the main branch keeps the merges as limited as possible.