Understanding version control concepts

So what do you get from Version Control software? All Version Control systems provide four important features: peace of mind, every time you make an update and store it in source code control, your files are backed up; history, not only are the contents of your files backed up, the actual changes you made and your comments about why you made them are also captured so that when you come back 3 months from now, you can easily see what you changed, and you can remember exactly why you did it. This is because each change is accompanied by a short message which after a bit of practice, you will be the master of composing in a terse, pithy, brief, succinct, compact, and to the point style; friction-free undo, this means you can easily move back to a previous version.

In some Version Control systems, this is done on a file-by-file basis, and in some the whole directory tree can be restored; and fearless experimentation, in addition to creating an automatic backup of your source code, you can also create a sandbox in which you can try out new features or make structural changes without worrying that you're breaking what already works. Version Control is even more important when working in a team providing three additional features: synchronization, when you store your changes in source control, your team members can easily update their copy of the source code from your changes; accountability, each time you store your changes, the Version Control system marks those changes with your user ID--this is crucial when working in a team environment as each time you grab changes made by someone else, you will be able to see who made the changes and why; and finally, conflict detection, when someone on your team makes a change that the Version Control system can't automatically merge with yours, the system will notify you and help you use differencing tools to resolve the changes.

Without a tool like this, you might easily overwrite someone else's changes and lose a critical update. If you're not already using Version Control software, you're probably already doing some sort of change control by hand. You might be using Save As to make backups of individual files, duplicating and/or compressing directories to take snapshots and hopefully copying those backups to an external drive or a cloud-based system. The most time-consuming part of doing Version Control by hand is trying to figure out the difference between sets of changes. So you end up with directories like MoneyMaker-Working, MoneyMaker-ShipIt, and MoneyMaker-FinalFinalWithBugFixes and then trying to figure out what's the difference between those three.

After you make the move to Version Control software, nearly everything is automatic. As you work, each new version is kept in a simple database-like system. Tracking changes from one version to another becomes the job of the Version Control system which can not only show you the changes, but it can help you remember why you made the change, because as I said before ,you're forced to add a comment each time you check in a change and make an update. You can also easily roll back to a specific version of either a single file or a whole set of files. And significant milestones can be marked by a process called tagging, or labeling.

That means you can get back to that exact state of the entire product, which can be especially useful when you have to fix a bug in release 2.3.11 you made last December. So if you're ready to let Version Control software help you keep track of what you're doing and why you did it, let's get started. Before we roll up our sleeves and actually dig in, there are six key terms we need to define and these work across all different kinds of Version Control systems, but they are key to understanding the basic process, so the first one is repository.

A Version Control system is an application or a set of applications that manage creating a repository, which is the name of the specialized database where your files and history are stored. In some systems, this is in an actual database, and in some systems this is done by creating a set of small change files which are identified by some identifier and managed by the software. The next is working set. Your files and folders can be organized into projects within the repository in a manner similar to how you manage files by keeping them in folders on your hard drive.

The files on your hard drive, from the point of view of the Version Control software, are considered your working set. You change the files in the working set and then update the repository to reflect those updates, automatically creating a backup and denoting the purpose of the changes in a process-- that's called add when you are adding new files or committing or checking in for existing files. Once you have added or updated files in the repository, you can easily revert your working set with any version of the data in the repository.

If you're working by yourself, you can grab an older version. If you are working in a team, you can grab files that have been updated by your team members. That process is either called updating or checking out, and finally as we talked about before, you can mark the state of an entire project tree or an entire repository with an identifier called either a tag, or a label depending on the vendor, when significant events occur such as shipping a release or delivering it to a client. Next step, we are going to take a look at a Version Control system in action.

First, we'll look at it conceptually, and then we'll open a command line and actually run a Version Control system so you can see it in action.