Version Control

Version Control is a practice that is not just used in software development but other domains like engineering and general documentation. Let us have a brief look at what it is all about.

When a single person is working on software, the version control may not seem to be of much use at the cursory glance. But if the software is intended to do anything more than a singular task, it would be prudent to use a version control system - it makes it easier for software development. (Note that I would use the word 'software' or 'code' but it would apply to any work). If a group of people are working on the same project, then version control system is certainly necessary.

There are many version control software out there - but you can apply the system just by following a certain set of processes. A version control system should do the following.

1. Maintain the revisions of a particular unit of code
2. Enable to go back to a particular revision
3. Enable branching and merging of code

The last one becomes important when a group of people work on a project.

A version control system lets you save the state of a code at all stages. Most systems employ the use of version numbers to maintain different states. This is sometimes visible to the user of the end product - the numbers like 1.0, 2.5, or multiple set of numbers get attached to the software.

Many times when you are working on a piece of code, and apply changes to it - there might be instances when things do not work as they should. That is the point, where the version control system becomes useful. You would be able to go back to the state of the code, just before you made those changes. You can either review that code to apply the change to the faulty version, or if not many versions were created after that version; you can start of from that point.

In cases of large projects, a group of people work on a software. Most of the times they would need to work on the same file or set of file. When such is the case, the particular person, takes out a branch from the main set of files, and works on it. The main version of code is usually called the 'head'. Once the development to that branch is complete, it is merged back into the main set of files. If changes have been done to different part of the same code file by two people, the code is reviewed and merged appropriately.

As I mentioned earlier, there are many different software available (both open source and commercial) for giving you version control. In some cases, you can implement the system just by following some processes like file naming standards and change documentation. These are big words, but they are quite simple to follow.

File naming standards usually involve appending a group of numbers to the end of the file name. The different groups are separated by a dot (.), dash (-), or an under score (_). The first number is usually the main set of version, and you can use further set of numbers to show smaller changes.

filename_v1.0
filename_v1.1
filename_v1.2
filename_v1.2.1
filename_v1.3
filename_v2.0

Change documentations is nothing but keeping a note of what change was done in the particular version when compared to the earlier version. You can give a brief description of the change, and additionally, the line numbers or other specifics where the changes were made in the file. These details are put in a document.

I use version control, both at my job and for my personal projects. I even use it when I am working on art projects. One advantage of using it in art projects (especially vector art) is that I can usually reuse the work from one project in another similar project.