I\'ve been developing websites for a few years now, and I\'ve never had the time or energy to learn about version control. Now, as I start one of the bigger projects I\'ve ever
git is one of the easiest things out there, honestly. subversion has a very large mindshare right now, and many of the people who have been using it have trouble learning git (different is hard), but if you don't have experience with either, one is not harder than the other.
The basic model with git is that you do some work and you record a snapshot of your work with a description of what makes it different from the previous snapshot.
It's trivial to see the difference between any two of these snapshots or perhaps "go back in time" and look at the entire state of your project at any prior point. All of these operations are roughly instant, and none require access to any particular server.
Being instant means that you gain a new freedom of experimentation. You will never fear doing some wild and crazy experiment that involves things like removing all of the css files and starting fresh. If it isn't working out quickly, you just toss the work away and go back. But being able to even try this will get you really far.
I like to describe this to newcomers as a well-managed undo coupled with a really awesome backup system. When you push your changes to another repository (e.g. github), you effectively have two copies of every state in your project. It quickly becomes impossible to lose work.
I'd like to emphasize that last point: If you have one computer you work on and you push your snapshots to github, the only way you can lose data is if both github is unavailable (or lost your data somehow) and your computer broke at the same time. If you have two computers you work on, three systems have to break. If you use git to deploy your tree somewhere, four computers have to break.