Querki's been built on git from the start, so I've been using it for a solid two years. But I confess, that decision wasn't made out of any deep analysis -- I had simply decided early on that Querki was going to be mostly open-source, and all open-source projects these days are on GitHub, so I went with the flow. I'm starting to realize now that I never truly *understood* git until recently, though.
The thing is, when you have decades of experience with Source Code Management tools (and I've been using them longer than most -- I started out using Intermetrics' homebrew derivative of RCS back in 1987, and built a pretty state-of-the-art GUI-based framework system for GM in the early 90s), you get certain assumptions very ground into your brain. The notion that there is a "master" server somewhere is very deep-rooted. Moreover, the notion that branching and merging is a Horrible, Painful, Agonizing, Fraught Process becomes -- well, basically it becomes a reflexive twitch. When you've received enough electric shocks, you learn not to reach for the cheese behind that door.
(Granted, some SCM systems have always been better than others. But none have been great, and spending a couple of years working with SourceSafe taught me to *deeply* distrust trying to do anything "fancy" in these systems. Actually, working with SourceSafe mostly taught me not to trust SourceSafe for *anything*, but that's another story.)
Somewhere in the past few months, though, I've finally started to *get* git, and the benefits of always working in branches. Take today for example. I started out spending an hour trying to make an enhancement (progress towards the concept of "Choices"), only to discover that it was going to be harder than I expected. Humph -- don't have time to deal with this before Pennsic. What do I do with this code? Well, there is this "stash" concept, to just stuff the code away for now -- that works. Wait, that's going to be a pain if it takes a month or two before I return to it. Try an experiment: create a new branch for this project, and unstash into there. *poof* -- I now have a branch to hold this work, to get back to when I want it.
Engineers who are used to more-traditional SCM systems (which is most folks in the corporate world), I'd encourage you to play around with git, and get a sense of it. It's radically different from traditional models, and I believe there are some things it's not ideal for. (Eg, versioning of large binary blobs.) But for code-management it's a hoot: when checkins are local and instantaneous you checkin more frequently, and the branch-early-and-often mentality really changes the way you work, by making it easier to keep projects going in parallel. It's optimized for distributed open-source projects, but even for a one-man show like mine, it turns out to work awfully well...