Source Control Basics Part 1

I’d thought I write a little bit about source control and how to use it to make your work more productive. Even if you’re a freelancer or you have a team, source control is always a good choice.

In this mini introduction to source control I will talk about the benefits and downsides of using such system. I will talk about check out, commit, rollback, merging, branching, tagging and more.

So what is source control ?

Source control simply makes developers’ life easier, by enabling a full undo history on their source code, eliminating conflicts such as when two developers works on the same file.

Such system has the ability to store multiple versions of the same file in a single centralized repository, enabling to rollback to an earlier version of a particular file. And it offers a lots more.

So how is this works? Simple. A developer creates a central repository somewhere on a computer, imports all the files in this repository (this is often called initial import) and when he wants to work on those files he simply checks it out from the repository. When he finished working with the files he simply puts the modified files back to the repository (this is called committing). The source control application keeps track of everything else.

So when a file is coming from the repository it is checked out and when it’s going to the repository it is committed.

Let’s say we done this, we worked on a file and committed back to the repository. Now the repository has two versions of the same file. The initial version and the modified version. Each version has a number, it’s called a revision number.

Now let’s say we’re not satisfied of the modified version of the file and we want the original one. No problem, we just simply rollback to an earlier revision number.

Let’s say we can’t decide which version of the file is good, we can’t see the difference between the two versions. With source control we can use diffs. This command simply shows the changes between the two files. By looking at the diff you can clearly see what changes has been made to that file.

Now think of many developers working on these files. How do you know which developer did what ? You can interrogate a so-called blame list for a specified file which essentially shows all the changes made to the file and the user who last modified it.

Another feature of these systems is the ability to tag a revision. It simply puts a label on the specified revision. For example milestone_1. Later on you can recall this state by simply referring to this label or tag.

Branching means that the source control splits the repository into two mirrored versions each called a branch. This is useful when you work on the source code heading towards the next milestone, but an older bug is found in the source code. Now you can assign one or two developers to fix the bug on the other branch not affecting the original so you can keep the development going on. The branch is isolated from others and doesn’t affects them. Later on, when the bug is fixed, you can merge the two branches together. You can do this with the merge command of the source control.

I hope you enjoyed this article, check back soon as I will write about Subversion and Git. Two major source control applications and how to use them.