Nowadays, software development is more and more distributed. Developers of a project can work at different geographic locations and/or time zones. One major problem of distributed development is communication. It is (more) difficult to talk with someone who lives at the opposite side of the Earth. This problem makes it easier than ever for your changes to break someone else’ code without notice, and vice versa.
Many measures have been devised to address this communication problem. One important facility is the distributed version control system (DVCS). DVCS allows each developer to have a local copy/clone of the entire repository, which means a relatively static code environment where the developer can commit changes without interfering other developers. This is a significant advantage.
The advantage of branchy development is basically along the same lines. By dedicating a new branch to a task (be it developing a new feature or fixing a bug), you create a even more static code environment for the development. The staticness there is “permanent” in the sense that even when you do pull or push the environment won’t change. The only changes in the branch are those by you and your coworkers (if any) working on the same task. Previously, I have mentioned three advantages to use a dedicated branch for a task. Another evident advantage is a clean revision history.
I advocate branching as often and as many as you can. The only exception is when the task is trivial and can be done in a single commit. Create a new branch when you start working on a new nontrivial task. Commit as often as you like in that branch. And merge the branch to the main develop branch when you are done. Each task, though nontrivial, should be reasonably small to avoid big-bang merges. I am also an advocate of workflow tools. Developers should use tools such as hgflow and gitflow to minimize their effort (in order of magnitude) on branching’s and merging’s. I myself truly enjoy branchy development with such tools.