What are the advantages of using branching as a solo developer?

Question

First off, I am aware that many questions have been asked about VCS as a solo developer, but they are often too broad. This concerns only branching, and still it has been marked as a duplicate...the supposed duplicate is, again, marked as another duplicate of another question that is too broad and doesn't concern branching specifically. That's how my question's unique.

What are the advantages, if any, of using branching as a solo developer? I've often seen it recommended even in a solo-dev context, but as far as I can see, beyond using a 'master' trunk for development, and branching off for working, release-ready code, I don't see how I could harness the power of branching (for example, to compartmentalize new features) without over-complicating the whole development process.

Answer 1

The advantages are mostly the same as for groups of developers. By using an always release-ready master branch, and feature branches for developing new features, you can always release off the master. Find an important bug while working on a feature? Switch branch, fix, release, switch back and continue developing.

Or maybe this is a hobby project and you just like being able to work a bit on this feature and a bit of that, as the mood strikes you. You're basically emulating a multiple-person team by time-slicing.

The implicit branching that DVCSs do on clones means that formal branches on the authoritative repository are less about coordinating people and more about coordinating development directions, and even a single person can do multiple of those.

Answer 2

Long running development

Branching for a single person team would be useful for a long-running development feature that otherwise does not fit into your release cycle.

You can take a branch for your multi-month spanning change and still be able to push whatever day-to-day bug fixes or changes from your main branch at regular intervals.

This has the advantage over 'switches' in a single branch in that your main branch is always in a deployable state and you are guaranteed that nothing in the long running feature has had an impact on other, previously tested code.

Experimental features

A branch can also be useful for features that you may wish to prototype up, but which may never make it into your deployed code. Completing these on a branch that my ultimately be thrown away means that you never pollute your main codebase unnecessarily.

Answer 3

I use it for critical website maintenance. I'm the sole developer yet I have a master, develop and issue branches.

My work process for site setup looks like this:

1. Make workable master branch. Do initial commit.

2. Checkout develop branch. Don't do anything, develop functions as a test buffer for merging into master.

3. Checkout issue branch. Code your issue, when it's done, pull it into develop, see if any issues arise, merge conflicts etc... fix those.

When enough issues are merged into develop for a release and develop has been tested for stability, pull develop into master.

   Master
     |
   Develop  - E
   / |  \  \
 A   B   C  D

That way you get a full testing collection in develop, where you can test stability, issues, etc... without having to risk hurting Master and having to roll back commits if they were harmful.

Also, by using individual branches for committing, you can "leave" work you already did, start fresh on something else to fix an more urgent issue and roll that out sooner.

In real life I usually have one issue branch, and pull that one in develop and then into master. Sometimes it's tedious, but once every two months at least I have to drop work at the drop of a hat because someone had an idea that I have to make RightNow™ and that way I can quickly switch back to a base state, make the thing and then afterwards continue where I was. Especially with large projects that take multiple weeks this is a godsent that I can quickly switch branches.

Consider this scenario: You always work on a main branch and you have AwesomeCodeThing™ in the works that leaves your Master branch in open heart surgery and a YugeBug™ pops up that needs urgent fixing otherwise thousands of users will complain to you about BigProblems™
The only way to quickly resolve your issue in such a scenario,

1. check your previous commits,
2. see when your last stable commit was(cursing is optional)
3. roll back to that commit
4. make fix, push fix out to production
5. solve all the conflicts and problems you now have trying to get back to AwesomeCodeThing™ status
6. give up, cry and start work over.(optional)

If you use branches:

1. Checkout master
2. create branch UrgentFix™ and fix stuff
3. pull UrgentFix™ into master
4. push to production
5. Merge master into develop
6. Merge develop into AwesomeCodeThing™
7. get a beer and continue working.

Answer 4

Branches make it easier to work on multiple features at once, which can be quite helpful when priorities change during the course of a project.

Say you decide a feature is more important now. Perhaps you urgently need to patch a critical bug in a live system. You could be working with a client on multiple features over a long period of time and may want to demo each feature's progress separately. Maybe you've just read about a nasty zero day exploit and want to get onto it before said client reads about it.

If you're using branches for each feature/hotfix it will typically be easier, cleaner and quicker to isolate and deploy these modifications rather than using a single branch for everything. This holds true whether you're a sole developer or part of a team.

As for an actual process, I find git flow works well. Daniel Kummer's git flow cheat sheet is a great resource, it's worth looking at even if you're not using git.

Answer 5

As mentioned by other posters, the advantages are substantially similar to working in teams: The ability to independently develop and test features, maintain a separate master branch for hotfixes/production deploys, experiment.

For me personally, I generally tend to work in master if I know the area I am working on very well, it just adds overhead to branch because I'll just merge them anyway.

However, if I have any hesitation about the changes I am making I will branch and only PR/merge once the branch behaves as expected and is generally fully tested. That way, if I discover an issue for which rolling back is the best course of action, it's a single commit instead of an entire series (I can never remember the syntax to rollback a series of commits but a single one is easy).