Software configuration management, of which Version Control is part, is a little more complex than keeping track of changes to files, although you can certainly start with that. But do read the Wikipedia articles linked above along with Joel Spolky's tutorial on Mercurial.
To start, choose one of Mercurial, GIT, or Bazaar, in that order, and install it along with tools for your IDE and operating system (I prefer Mercurial with HGE for Eclipse).
- Initialize a repository from your working directory (hg init with Mercurial)..
- Decide which files and directories you want to track and which not. The general rule is not to track files that are generated by compilers and other tools.
- Use the command to add the files and directories to the repository (hg add for Mercurial).
- Tell the tool about the patterns for the files you don't want to track (edit .hgignore for Mercurial).
- Perform a commit to track the original versions (hg ci).
- Perform a commit after each logical milestone, even if it's a small one.
- Add new files as you create them.
- Repeat the last two.
- Backup your working directory and the repository as frequently as reasonable.
With your files in the repository, you can know the differences between any two versions of a file or directory, or the complete project (hg diff), see the history of changes (hg hist), and roll back changes (hg up -r).
It is a good idea to tag (hg tag) the repository before publishing your code so there's an easy way of going back to exactly what you published for amendments or comparisons.
If you want to experiment with a different line of development, do it in a simple branch by cloning the main repository (hg clone) and not pushing back until the experiment is conclusive. It is as easy as having a different working directory for the experiment.
If the experiment is for a new, upgraded version then clone and then branch (hg branch) so you may keep all copies of the repositories updated without one experiment interfering with the other.
Linus Torvalds (who deals with tens-of-thousands of files and millions of lines of code in his projects) gave a talk at Google about why the tool can't be CVS, SVN, or any of the many free and commercial ones around; it is very much worth watching.