Use Mercurial. There's http://hginit.com http://hginit.com. Given your comment about "I didn't need a tuturial for Subversion", though, maybe you'll find that

Use Mercurial. There's http://hginit.com http://hginit.com. Given your comment about "I didn't need a tuturial for Subversion", though, maybe you'll find that inadequate, too. As someone who tried using SVN before ever touching hg or git or its forebears, I found SVN baffling. To me, the DVCSes make sense. HgInit's "Subversion Re-education" page says: > Mercurial separates the act of committing new code from the act of inflicting it on everybody else. The fact that this isn't the case in SVN is mystifying to me. I still struggle with git. In fact, I don't use it, largely because I still don't know how to use it. Note how I said that "the DVCSes make sense". I say that, because I can read "Understanding Git Conceptually" <http://www.sbf5.com/~cduan/technical/git/>--which http://www.sbf5.com/~cduan/technical/git/>--which a number of HN commenters have posted before--and I get it. The problem is not that I don't understand the concepts backing git. It's that I don't understand how these concepts map onto git's infuriatingly obtuse UI. So use Mercurial. Because, a) it's better (read: nicer to use), and b) when you use Mercurial, it comes with the benefit that you're helping inoculate the dev world against a DVCS monoculture. If it helps, know this: I write as someone whose use case is largely the one you outline. I mostly find myself working alone, on a side project of mine where I'm the only committer. # Crystallize your changes in a revision marked with your # commit comment: hg commit That's it, pretty much. Occasionally you'll need to do an hg addremove to make sure Mercurial isn't ignoring any new files you've introduced (hg add and hg remove if you want to do things manually), and an hg mv whenever you need to move things around. Everything ramps up pretty sensibly and steadily from there, so that you're really only spending the mindspace to pay for the features you're really using. For example, if you have a public-facing repo: hg push # read as "publish", if it helps. Do this, occasionally preceded by an hg out (when you find that you want to see what you'll be pushing), and you're good to go.