I had written up a long spiel about why versioning in general is awesome and what you can use it for, but I promptly erased it because there's already enough literature on the topic that you can go research that on Google somewhere. I'm here to talk about Git and why it's helped me out even on my single-developer projects.
Git is a distributed version control solution like Mercurial. I've not used Mercurial much- it could be just as good as Git or even better and I will never know it. I've used Git since I came back from my 2008-2009/10 hiatus. My first repository was bProxy, and I currently have 28 repositories on my Git server (including the one for my budgets, another for my timesheets for work, and the repository that holds this website). We also use Git at work a lot.
As a developer on solo projects, I find Git to be invaluable. As someone that oftentimes gets side-tracked on stuff that I shouldn't really be doing, I find the staging process to be absolutely amazing. It's not a unique concept to Git, but it's exposed in such a way that I'm not obligated to do *anything* with it and getting to it is incredibly easy. A simple 'git status' reveals to me what files I've added, removed, or modified, and I can choose which parts of this I'd like to actually commit. This is really helpful when I stopped in the middle of implementing feature A to work on feature B, and I've suddenly got a half-broken implementation of A and a fully-functional implementation of B. I can choose to commit only what I needed to add or modify (using git add) for feature B and not introduce the half-broken implementation of A to the rest of my project.
Other than that, easy branching and tagging (via git branch and git tag respectively) as well as switching between branches (with git checkout) or checking out a commit with a tag (via git checkout, again). Prior to my hiatus, I had been experimenting with TortoiseSVN, which seemed to be the most used client for SVN for Windows. I don't recall the specifics, but I do recall that branching and tagging was more painful than 'git branch [branch_name]' and 'git tag [tag_name]'.
Cloning of projects is also a great feature that pretty much everyone uses extensively. If you're copying a repository from one place to another, be it locally or remotely, you're going to use this. `git clone` will clone the exact state of the given repository and add the `origin` remote to your repository for you, so that you can git pull and git push without having to specify what branch your master branch is tracking, or where to push to by default.
Remotes are another topic of interest as far as work-flow. Say you have two repositories, 'audcom' and 'audcom-dev' (which I do). 'audcom-dev' was cloned from 'audcom', so you can pull within it and it automagically merges the `master` branch in the local repository (a tracking branch) with the the origin's `master` branch. Now, say we made some changes to 'audcom-dev' and wanted to bring those into the master, as you might do when testing CMS updates or module updates? I can create a remote in 'audcom' to point to dev, then 'fetch' and 'merge'. Creating the remote is as simple as `git remote add dev /srv/http/sites/audcom/audcom-dev` within my /srv/http/sites/audcom/audcom directory, and you only have to do that once. From there, you can simply 'git fetch dev' and 'git merge dev/master' and merge the changes from dev's 'master' branch into the current branch.
That's all I can think about for now. I'm sure I'll find more to mention on the subject, but we'll save that for another time.