Version Control System

A Visual Guide to Version Control

Version Control (aka Revision Control aka Source Control) lets you track your files over time. Why do you care? So when you mess up you can easily get back to a previous working version.
You’ve probably cooked up your own version control system without realizing it had such a geeky name. Got any files like this? (Not these exact ones I hope).

• KalidAzadResumeOct2006.doc
• KalidAzadResumeMar2007.doc
• instacalc-logo3.png
• instacalc-logo4.png
• logo-old.png

It’s why we use “Save As”. You want the new file without obliterating the old one. It’s a common problem, and solutions are usually like this:

• Make a single backup copy (Document.old.txt).
• If we’re clever, we add a version number or date: Document_V1.txt, DocumentMarch2007.txt
• We may even use a shared folder so other people can see and edit files without sending them over email. Hopefully they relabel the file after they save it.

Advertisement: Use Springloops for your secure and rapid web deployment. Easily share and deploy your code. Free & paid plans and no contracts: Try it today!

So Why Do We Need A Version Control System (VCS)?

Our shared folder/naming system is fine for class projects or one-time papers. But software projects? Not a chance.
Do you think the Windows source code sits in a shared folder like “Windows2007-Latest-UPDATED!!”, for anyone to edit? That every programmer just works in a different subfolder? No way.
Large, fast-changing projects with many authors need a Version Control System (geekspeak for “file database”) to track changes and avoid general chaos. A good VCS does the following:

• Backup and Restore. Files are saved as they are edited, and you can jump to any moment in time. Need that file as it was on Feb 23, 2007? No problem.
• Synchronization. Lets people share files and stay up-to-date with the latest version.
• Short-term undo. Monkeying with a file and messed it up? (That’s just like you, isn’t it?). Throw away your changes and go back to the “last known good” version in the database.
• Long-term undo. Sometimes we mess up bad. Suppose you made a change a year ago, and it had a bug. Jump back to the old version, and see what change was made that day.
• Track Changes. As files are updated, you can leave messages explaining why the change happened (stored in the VCS, not the file). This makes it easy to see how a file is evolving over time, and why.
• Track Ownership. A VCS tags every change with the name of the person who made it. Helpful for blamestorming giving credit.
• Sandboxing, or insurance against yourself. Making a big change? You can make temporary changes in an isolated area, test and work out the kinks before “checking in” your changes.
• Branching and merging. A larger sandbox. You can branch a copy of your code into a separate area and modify it in isolation (tracking changes separately). Later, you can merge your work back into the common area.

Shared folders are quick and simple, but can’t beat these features.