Local Version Control Systems

These are the first VCSs created to manage source code. They worked by tracking the changes made to files in a single database that was stored locally. This means that all the changes were kept in a single computer and if there were problems, all the work were lost. This also means that working with a team was out of the question.

One of the most popular local VCSs was Source Code Control System or SCCS, which was free but closed source. Developed by AT&T, it was wildly used in the 1970s until Revision Control System or RCS was released. RCS became more popular than SCCS because it was Open Source, cross-platform, and much more effective. Released in 1982, RCS is currently maintained by the GNU Project. One of the drawbacks of these two local VCSs was that they only worked on a file at a time; there was no way to track an entire project with them.

To help you visualize how it works, here’s Figure 1-5 which shows an illustration of a simple local VCS.

As you can see in Figure 1-5, everything is on the user’s computer, and only one file is tracked. The versioning is stored in a database managed by the local VCS.

Centralized Version Control Systems

Centralized VCS (CVCS) works by storing the change history on a single server that the clients (authors) can connect to. This offers a way to work with a team and also a way to monitor the general pace of a project. They are still popular because the concept is so simple and it’s very easy to set up.

The main problem was that, like local VCS, a server error can cost the team all their work. A network connection was also required since the main project was stored in a remote server.

You can see in Figure 1-6 how it works.

Figure 1-6 shows that a centralized VCS works similarly to a local VCS, but the database is stored in a remote server.

The main problem faced by team using a centralized VCS is that once a file is being used by someone, that file is locked and the other team members can’t work on it. Thus, they had to coordinate between themselves just to modify a single file. This creates a lot of delays in development and is generally source to a lot of frustration for contributors. And the more members are on the team, the more problems arise.

In an effort to counter the problems of local VCS, Concurrent Version System or CVS was developed. It was Open Source and could track multiple sets of files instead of a single file. Many users could also work on the same file at the same time, hence the “concurrent” in the name. All the history was stored in a remote repository, and the users would keep up with the changes by checking out the server, meaning copying the contents of the remote database to their local computers.

Apache Subversion or SVN was developed in 2000 and could be everything that CVS could, with a bonus: it could track non-text files. One of the main advantages of SVN was that instead of tracking a group of files like the previous VCS, it tracks the entire project. So, it is essentially tracking the directory instead of files. That means that the renaming, adding and removing are also tracked. This made SVN, along with it being Open Source, a very popular VCS; and it is still wildly used today.

Distributed Version Control Systems

Distributed VCS works nearly the same as centralized VCS but with a big difference: there is no main server that holds all the history. Each client has a copy of the repository (along with the change history) instead of checking out a single server.

This greatly lowers the chance of losing everything as each client has a clone of the project. With a distributed VCS, the concept of having a “main server” gets blurred because each client essentially has all the power within their own repository. This greatly encouraged the concept of “forking” within the Open Source community. Forking is the act of cloning a repository to make your own changes and have a different take on the project. The main benefit of forking is that you could also pull changes from other repositories if you see fit (and others can do the same with your changes).

A distributed Version Control System is generally faster than the other types of VCS because it doesn’t need a network access to a remote server. Nearly everything is done locally. There is also a slight difference with how it works: instead of tracking the changes between versions, it tracks all changes as “patches.” This means that those patches can be freely exchanged between repositories, so there is no “main” repository to keep up with.

Figure 1-7 shows how a distributed VCS works.

BitKeeper SCM was a proprietary distributed VCS released in 2000 which, like SCCS in the 1970s, was closed source. It had a free “Community Version” that lacked many of the big features of BitKeeper SCM, but since it was one of the first distributed VCSs, it was pretty popular even in the Open Source community. This popularity of BitKeeper plays a big role in the creation of Git. It is now an Open Source software, after having its source code released under the Apache License in 2016. You can find the current BitKeeper project on www.bitkeeper.org/; the development has slowed down, but there is still a community contributing to it.

What can Git do?

Remember all those problems we tried to solve at the beginning of this chapter? Well, Git can solve them all. It can even solve problems you didn’t know you had!

One of the main features of Git is its Branching system. A branch is a copy of a project which you can work on without messing with the repository. This concept has been around for some time, but with Git, it is way faster and more efficient. Branching also comes along with Merging, which is the act of copying the changesets done in a branch back to the source. Generally, you create a branch to create or test a new feature and merge that branch back when you are satisfied with the work.

There is also a simple concept that you might use a lot: Stashing. Stashing is the act of safely putting away your current edits so that you have clean environment to work on something completely different. You might want to use stashing when you are playing around or testing a feature but need to work on a new feature in priority. So, you stash your changes away and begin to write that feature. After you are done, you can get your changes back and apply them to your current working environment.

As you can see, the commands are pretty self-explanatory. Don’t worry about knowing all of them by heart; you will retain them one by one when we will properly begin the learning. And you will not also use them all the time, you will mostly use git add and git commit. You will learn about each command, but we will focus on the commands that you will likely use in a professional setting. But before that, let’s see the inner working of Git.

How does Git work?

Unlike many Version Control Systems, Git works with Snapshots, not Differences. This means that it does not track the difference between two versions of a file, but takes a picture of the current state of the project.

This is why Git is very fast compared to other distributed VCSs; it is also why switching between versions and branches is so fast and easy.

Remember how a centralized Version Control System works? Well, Git is the complete opposite. You don’t need to communicate with a central server get work done. Since Git is a distributed VCS, every user has their own fully fledged repository with their own history and changesets. Thus, everything is done locally except the sharing of patches or changesets. Like previously said, a central server is not needed; but many developers use one as convention as it is easier to work that way.

Speaking of patch sharing, how does Git know which changesets are whose? When Git takes a snapshot, it performs a checksum on it; so, it knows which files were changed by comparing the checksums. This is why Git can track changes between files and directories easily, and it also checks for any file corruption.

So, basically Git works as follows: you modify the files, add each file you want to include in the snapshot to the staging area (git add), then take the snapshot and add them to the database (git commit). For the terminology, we call a modified file added to the staging area “staged” and a file added to the database “committed.” So, a file goes from “modified” to “staged” to “committed.”

What is the typical Git workflow?

To help you visualize all that we talked about in this section, here is a little demo of what a typical workflow using Git is like. Don’t worry if you don’t understand everything right now; the next chapters will get you set up.

This is your first day of work. You are tasked to add your name to an existing project description file. Since this is your first day, a senior developer is there to review your code.

The first thing you should do is get the project’s source code. Ask your manager for the server where the code is stored. For this demo, the server is GitHub, meaning that the Git database is stored on a remote server hosted by GitHub and you can access it by URL or directly on the GitHub web site. Here, we are going to use the clone command to get the database, but you could also just download the project from the GitHub web site. You will get a zip file containing and the project files with all its history.

Git then downloads a copy of the repository in the current directory you are working from. After that, you can enter the new directory and check its contents as shown in Figure 1-8.

If you want to check the recent changes made to the project, you can use the “log” command to show the history. Figure 1-9 shows an example of that.

Even if another coworker changed the same file as you, the risk of conflicts is low because you only modified a line. Conflicts only arise when the same line has been modified by multiple people. If you and your coworkers changed different parts of the file, everything is okay.

Figure 1-10 shows the commands we used and the results.

It’s that simple! And again, don’t worry if you don’t understand everything yet. This is just a little demo of how Git is usually used. It is also not very realistic: no manager would give a new recruit an all-access pass to their main repository like that.