Till recently my development workflow was the following:
- Get the feature from product owner
- Make a branch (if feature is more than 1 day)
- Implement it in a branch
- Merge changes from main branch to my branch (to reduce conflicts during backward merging)
- Merge my branch back to main branch
Sometimes there were problems with merging, but in general I liked it.
But recently I see more and more followers of idea to not make branches as it makes more difficult to practice continuous integration, continuous delivery, etc. And it sounds especially funny from people with distributed VCS background who were talking so much about great merging implementations of Git, Mercurial, etc.
So the question is should we use branches nowadays?
Best Answer
Unless you are all working out of the same working tree, you are using branches, whether you call them that or not. Every time a developer checks out into his working tree, he creates a separate local branch of development, and every time he checks in he does a merge. For most teams, the question isn't if you use branches, the questions are how many and for what purpose?
The only way to do truly "continuous" integration is for everyone to work out of the same working tree. That way, you immediately know if your changes adversely impact someone else's. Obviously, that's untenable. You need a certain degree of isolation in a branch in order to accomplish anything, even if that "branch" is just your local working directory. What's needed is a proper balance of integration and isolation.
In my experience, using more branches improves the degree of integration, because the integration is done with precisely the people it needs to be done, and everyone else can more easily isolate non-related problems as required.
For example, I spent the last day tracking down three recently introduced integration-related bugs in our build that were blocking my "real" work. Having done my due diligence in reporting these bugs to the people who need to fix them, am I now just supposed to wait until they are finished to continue my work? Of course not. I created a temporary local branch that reverts those changes so I can have a stable baseline to work against while still receiving the latest changes from upstream.
Without the ability to make a new branch for that purpose, I would be reduced to one of three options: either revert the changes in the central repo, manually maintain the patches that revert them in my working tree and try not to accidentally check them in, or back out to a version before those bugs were introduced. The first option is likely to break some other dependency. The second option is a lot of work, so most people choose the third option, which essentially prevents you from doing more integration work until the previously found bugs are fixed.
My example used a private local branch, but the same principle applies to shared branches. If I share my branch, then maybe 5 other people are able to continue on with their primary tasks instead of performing redundant integration work, thus in aggregate more useful integration work is performed. The issue with branching and continuous integration isn't how many branches you have, it's how frequently you merge them.