117

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.

  • 14
    I'm sorry, I admit I'm not very experienced in the StackExchange model, but am I to understand that 'best practices', or any other question that doesn't have a single, deterministic answer are frowned upon, or even not allowed to be discussed? I see plenty of opinion-based examples of supposedly valid questions even in the 'related' section of this question, such as softwareengineering.stackexchange.com/questions/286928 or softwareengineering.stackexchange.com/questions/132730 – flatterino Jan 16 '18 at 9:18
  • 8
    While I agree with Man that this question isn't an exact duplicate (the scope differences are significant), the dupe of the dupe target question gnat linked does happen to have answers covering the topic you're interested in -- is there something those answers didn't cover that you want to hear more about? – jrh Jan 16 '18 at 13:34
  • 4
    My thinking was that while that question does cover that topic, it does so tangentially (the user asks 3 different questions related to different aspects of branching), and in fact the question itself was closed for being 'too broad' for that very reason. I was hoping to start a discussion about this very specific feature of VCS in this similarly specific context. To answer your question, so far, several aspects of it have been mentioned here (in the replies and comments on these replies) that aren't mentioned in the replies to the question you referenced. Thank you all for your contributions. – flatterino Jan 16 '18 at 14:48
  • 1
    Possible duplicate of As a sole developer (for now), how should I be using Git? – Doc Brown Jan 16 '18 at 14:49
  • 3
    Dan, again...the question you linked asks "As a sole developer, what Git or GitHub features could I take advantage of that would benefit me right now?". A possible reply to that question, among others, could be "branching". That wouldn't be an answer to my question. Also, it was closed as too broad for that same reason. Please read the explanation on top of my question. I've had to edit my post 3 times now... – flatterino Jan 16 '18 at 14:57
199

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.

  • 1
    Exactly. Groups don’t have to use branches, either—I’ve worked for teams that didn’t. Granted, that was mostly out of unfamiliarity with git, and all of those teams learned to use branches as problems with not using them appeared, but those problems would apply to a solo developer just as well. – KRyan Jan 18 '18 at 2:47
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.

2

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).

16

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.
  • 13
    Getting a beer before continuing is non-optional. – JamesB Jan 16 '18 at 17:54
  • 4
    @JamesB Getting a beer before starting is non-optional :) – Chris Cirefice Jan 17 '18 at 14:07
42

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.

protected by gnat Jan 17 '18 at 9:01

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.