If you google
version control system, the first hit is the wikipedia article on Revision Control. Did you read that?
Basically, here is the problem. You write some code. It works. Then you start to modify it. Now it doesn't work. What did you change? How do you get back to what worked? Some people save copies of working code and then can compare old code to new code. A VCS automates this process. You tell the VCS when you are done with changes ("checkin"), and you can ask the VCS for either the current or any older version of the code ("checkout").
Now add to this that you might not be the only person working on the code. How do you keep the changes made by a dozen people in sync. And how has the "correct" version of the code. A VCS also solves that problem because it is in effect a source code database. When you want ot made changes ot the source code, you "checkout" the code form the VCS. When you are done, you check the code back into the VCS.
And then consider what happens after you release software to users. They find bugs. You need to give them a fix. But you've already made a lot of changes which you are not ready to give them. A VCS will let you "branch" you code changes so that you can apply bug fixes to the same source that you released earlier, while still continue adding new features to another branch (usually referred to as the "trunk"). A lot of VCS literature spends a lot of time talking about branching. But for personal app development you can usually ignore that. For my personal apps I use a VCS simply to store working states of the source code (what I described in my first paragraph).
The best way to learn more about what VCSs do is to play with them. Some popular free ones include Subversion, git and Mercurial. Also, you might as well install all three of these because open source projects tend to use them to manage their source, and so if you ever will need the source for anything, you'll need the VCS's tools to get the source.