Git – What Is It?

One of the many technologies that you will encounter in the world of test automation and coding in general is version control, and one of the most common forms of that and one you’re most likely to use is Git. And for good reason too.

In the modern world of coding, there is simply no way round using version control so as complicated and as daunting as it may seem (and I’m here to try and help show that it isn’t), it is absolutely something you must get to grips with. 

Let’s start off in this first article by explaining what version control is and how it is used.

Put simply, version control is a category of software that allows an individual or team to track and manage changes to source code over time. By keeping track of every change to every file in its own kind of database, developers are able avert disaster, either by human error or worse, failure of technology and turn back to any point in time for any particular file.

When software is written in teams, it’s not uncommon for several developers to be working inside a solution at any one time, maybe even working on the same file. Without version control, this becomes a difficult task to prevent concurrent work from conflicting. The other issue is that changes made to one part of the project may introduce bugs to other parts of the project worked on by other developers, or it may just be incompatible altogether. Again, without version control, fixing these issues can be a lengthy process, and work is completely blocked until such a time where all the problems have been resolved.

Version control however fixes the above problems and many more. By allowing developers to work on different versions of the code, by working on their own branches, they are free to make changes unique to their branch that are not at risk from other changes until they are ready to be committed to a common branch.

At the heart of version control systems lies a remote repository, a collection of all the files associated with the source code. This repository is where the database is stored that contains history of every file and every change made to that file. When a developer is working on the source code in this repository, they must make a local copy of it, which they do via cloning. This makes an exact copy of the files in that repository at the time it was cloned. This means having a local copy of the version control database. The local changes made by the developer are then stored in this local database, and when the time comes to commit the code to the remote repository, the local database and its changes are stored in the remote database. Now, all the changes made by the developer are available to every one, but more importantly, if those changes were to break anything, they can be rolled back to a previous point in time.

Making changes to a file before it is pushed in to the remote repository is a three step process. The first step is once the changes are made, this file is then considered “modified”. This might seem self explanatory, but it’s important to understand the process as well as the terminology involved. Once a file is modified, it can then stay there for as long as is necessary, until it is ready for the developer to push the changes. For them to do this, they need to “stage” the file, staging a file simply means it has been selected to be pushed to the remote repository. Sometimes this is simple because a developer wants to commit all modified files, but other times it may be a more selective process. There will be a process in which the version control system of choice creates a staging area, which in the context of Git, will be a simple file containing a list of files to be staged. 

Finally, once a file has been modified and then staged, it has to be committed. Committing a file is to tell the version control that you at some point will be pushing these changes. A commit doesn’t necessarily mean it will be available to everyone straight away. A commit needs to be pushed for it to reach the remote repository.

And there you have it, a very high level look at version control, both what it is and how it works. As I mentioned earlier, the most common form of version control you are likely to use in both a commercial or hobbyist environment is Git. And in the next article, we will look at what makes Git so good and how you can set it up on your machine for you to use and begin learning.