Sometimes we call it "version control." Sometimes we call it "SCM," which stands for either "software configuration management" or "source code management." Sometimes we call it "source control." I use all these terms interchangeably and make no distinction between them (for now anyway -- configuration management actually carries more advanced connotations I'll discuss later).
By any of these names, source control is an important practice for any software development team. The most basic element in software development is our source code. A source control tool offers a system for managing this source code.
There are many source control tools, and they are all different. However, regardless of which tool you use, it is likely that your source control tool provides some or all of the following basic features:
- It provides a place to store your source code.
- It provides a historical record of what you have done over time.
- It can provide a way for developers to work on separate tasks in parallel, merging their efforts later.
- It can provide a way for developers to work together without getting in each others' way.
My goal for this series of articles is to help people learn how to do source control. I work for SourceGear, a developer tools ISV. We sell an SCM tool called Vault. Through the experience of selling and supporting this product, I have learned something rather surprising:
Nobody is teaching people how to do source control.
Our universities often don't teach people how to do source control. We graduate with Computer Science degrees. We know more than we'll ever need to know about discrete math, artificial intelligence and the design of virtual memory systems. But many of us enter the workforce with no knowledge of how to use any of the basic tools of software development, including bug-tracking, unit testing, code coverage, source control, or even IDEs.
Our employers don't teach people how to do source control. In fact, many employers provide their developers with no training at all.
SCM tool vendors don't teach people how to do source control. We provide documentation on our products, but the help and the manuals usually amount to simple explanations of the program's menus and dialogs. We sort of assume that our customers come to us with a basic background.
Here at SourceGear, our product is positioned specifically as a replacement for SourceSafe. We assume that everyone who buys Vault already knows how to use SourceSafe. However, experience is teaching us that this assumption is often untrue. One of the most common questions received by our support team is from users asking for a solid explanation of the basics of source control.
Best Practice: Use Source Control
Some surveys indicate that 70% of software teams do not use any kind of source control tool. I cannot imagine how they cope.
Throughout this series of articles, I will be sprinkling Best Practices that will appear in sidebar boxes like this one. These boxes will contain pithy and practical tips for developers and managers using SCM tools.
We need some materials that explain how source control is done. My goal for this series of articles is to create a comprehensive guide to help meet this need.
Ideally, a series of articles on the techniques of source control would be tool-neutral, applicable to any of the available SCM tools. It simply makes sense to teach the basic skills without teaching the specifics of any single tool. We learn the basic skills of writing before we learn to use a word processor.
However, in the case of SCM tools, this tool-agnostic approach is somewhat difficult to achieve. Unlike writing, source control is simply not done without the assistance of specialized tools. With no tools at all, the methods of source control are not practical.
Complicating matters further is the fact that not all source control tools are alike. There are at least dozens