What Git is?

Many articles don’t bring out the clear power of Git as a Version Control System.

Git logo

Anyway, here is what you need to know about Git. Git is a version control system ( VCS ) / Source Code Management (SCM), Revision Control System (RCS). Git is the most used distributed / decentralized version control system. It helps to push the code to the Git server just like Gitlab. We can simply understand the version control system as a simple database since it takes notes and saves the snapshots of your completed code. Anytime you can check out your files, basically to see how far your code base has come from just like every second adds to a minute. So every time you save new files, there is a previous snapshot taken of your code and the new one saved. The snapshots here are the versions of your code, so Git helps to control, and manage the version of your code.

We shouldn’t confuse a Version Control System with a backup or deployment system. For starters what is a “ deployment system”? The deployment system is the mechanism through which applications, modules, updates, and patches are delivered from developers to users. I hope you find it different after reading this article. A version control system records the changes you make to your project’s files. This is what version control is about. It’s as simple as it sounds.
Many are asking why the Version Control System is.

There are many reasons why we have to use the Version Control System, just like how these next steps will help enlighten us about the benefits of the Version Control System.

Firstly, “Collaboration” let’s define Collaboration as a working practice whereby individuals ( here we shall refer them as developers ) work together for a common purpose to achieve a better output or some would say a better benefit. Without a Version Control in place, imagine you are looking forward to creating a new application but in a group of developers. At times you will need to work on a file without anyone breaking it up or even interrupting the code. Ideally, it would be crazy to find a developer shouting in the office area trying to let everyone know they shouldn’t tamper with the specific file he is currently working on. So Git lets you do your code and then update the version (snapshot) of the current code base you worked on. With this power, you can collaborate on a project since you share the different kinds of versions to create one final version.

collaboration at work

Like we have seen previously the Version Control System helps store the versions of your code. Everyone would need to save the different versions of the code base they have been from since saving a version of your project after making changes is an essential habit for developers. But without a Version Control System in place, this becomes monotonous/tiresome, and complex. So the Version Control System saves the changed files to the disk, but you see all the previous files stored in the Version Control System when you need them. All you gotta do is request any version (snapshot) from the Version Control System.

Knowing that the Version Control System can keep track of the previous versions, another benefit of using the Version Control System is that you can restore the previous version of your code. For instance, you are working on the latest version of your file, but you mess up the code and the output is scrappy, all you have to do is to restore the previous version and you will be good to go. This gives developers relaxation when coding alongside git as the Version Control System.

Understanding what you changed is another benefit of the Version Control System. Every time you save a new version of your project, the Version Control System requires you to provide a short description “commit” of what was changed. Most of you didn’t understand the meaning of this, but let me dive deeper. A commit is that short message you add to your new version of code, to let developers/ people you are working with know what changes are in the new version. Sometimes this also helps you recall what exactly you changed. So this is a great advantage of Git as a Version Control System.

The fun fact about Git being your Version Control System, it can act as a backup for restoring your repository. Trust me it’s true, for instance, if your main cluster or server breaks down and you lose all the files, all you have to do is to ask for any of the team member’s laptops/machines since they will always have the repository cloned and installed on their machines. I know I have introduced new terms here “cloned” and “repository” but I promise we shall leave no stone unturned.

Before you go to the “cloning” experience, we will try to get an understanding of the Git workflow, where we will find the “repository“Actually let’s define Repository as the most basic building block of the Version Control System. Think of a repository as a kind of database where your Version Control System stores all the versions and metadata that accumulate in the course of your project. In Git, the repository is just a simple hidden folder named “.git” in the root directory of your project.

A quick reminder, we need to have the Version Control System installed on your machine. So let’s learn how you can install Git locally in a few steps. Remember, it can be installed on all Operating Systems, but unfortunately today we shall install Git for the Linux system in the steps below which we will run in the terminal or bash.

If you are working on distribution based on Debian, for instance, Ubuntu, Git packages are available via apt :

$ sudo apt-get install git-all

And for Fedora use dnf / yum:

$ sudo dnf install git-all

You can also find more instructions about installing Git here. With all that done you can check for the version of Git you have installed on your machine. Using the git command below

$ git --version

It should give an output like this

Git version check

Having fulfilled one of the major prerequisites, we shall start on getting a repository on your local machine. It can be done in two ways :
Firstly, if you have a project locally on your computer that is not yet under Version Control, you can initialize a new repository for this project. By just running this “git init” command in that directory containing the repository from the terminal/bash. The git init command will initialize the repository you are currently working on. As you can see below.

using git init

Secondly or the last option, if you’re getting on board a project that’s already running, chances are there is a repository on a remote server (on the internet or your local network). You’ll then probably be provided with a URL to this repository that you will then “clone” (download/copy) to your local computer. Here let’s understand what cloning means. Cloning a repository pulls down a full copy of all the repository data that a remote account has then, including all versions of every file and folder for that project. So when cloning we use the URL which is given in three types; HTTPS, SSH, and Github CLI. But for starters, we are gonna use the HTTPS type.
Note: The URL comes with an extension “.git” for all the URL types except the GitHub CLI, which is to help initialize the cloned repository during the cloning (downloading) process.

repository cloning

But don’t forget to have all this you will have to create a GitHub account. After cloning you will need to learn more basic git commands to use git or else it won’t be easy for you. You can use this for starters to get on track. And for ways to practice the commands you can this article.

Let’s end here for today. I know you are exhausted!