Version control has been around for quite a few years. However, I still get asked some basic questions about what it is and how it helps. This post will briefly explain the main point of version control. The context will specifically revolve around source code version control.
There are a couple different types of version control systems (VCS). There are VCSs that are architected around a central repository, like Subversion and CVS. Then there are distributed VCS (DVCS). Git and Mercurial are just two examples of the newer DVCS. However, in both types of environments there is usually an “annointed” central repository. That is a proper Subversion server or possibly a GitHub repository. The following illustrations will be based on this scenario. So let’s dive in…
The server will need to have a repository created before a developer can copy it to their local machine. The initial creation of the repository varies from product to product. For right now, all you need to know is that there is an initial space on the server. I will call this version “A”.
Each developer will work on their local copies. Their local copies will be based on version “A”. However, since they should not be doing the same task, their versions will be different. Therefore, two more versions are being created simultaneously; versions “B” and “C”.
Developer 2 now finishes his task and attempts to push it to the server. However, the server gently informs the developer that his version is based off of a stale version. This is one of the top reasons to use a version control system. This feature is leaps and bounds better than simply having a network share that developers manually update. This ensures that previous edits do not get overwritten when newer edits are created.
Developer 2 must first pull down the changes made in version “B” and merge his changes before he is able to push it to the server. This sounds like a complicated process. However, most modern version control systems are sophisticated enough to perform the merge automatically on the developer’s local copy. There are times when conflicts arise (ie: Developer 1 and 2 both modified the same line in the same file). This is where some VCS products are more sophisticated than others. Regardless of how the merge occurs, Developer 2 will now have the combination of versions B and C on their local system.
That is the basic fundamentals of a version control system. One might notice a nice benefit by looking at the server line in the drawings. The server keeps track of all of the previous versions including what changed, when and by who. This record keeping can be a life-saver when regression or other bugs creep into the source.
I hope this helps provide a basic understand of version control systems. If you have any questions, please leave them in the comments.
UPDATE: It appears as though this article has been translated into Chinese (link).