Introduction to Git VCS

Introduction to Git

Git is a free and Open Source version control system, a technology used to track older versions of files, providing the ability to roll back and maintain separate different versions at the same time. Git is a free ware and is a successor of SVN and CVS, two very popular version control systems of the past. First developed by Linus Torvalds (the creator of Linux), today is the go-to system which you can’t avoid if you make use of Open Source software.

How does it work?

Git is a distributed system. Many developers can clone a repository from a central location, work independently on some portion of code, and then commit the changes back to the central location where everybody updates.

Git makes it very easy for developers to collaborate on a codebase simultaneously and provides tools they can use to combine all the independent changes they make.

A very popular service that hosts Git repositories is GitHub, especially for Open Source software, but we can also mention Bit Bucket, Git Lab and many others which are widely used by teams all over the world to host their code publicly and also privately.


Installing Git is quite an easy task on most of operating systems.

For windows:

Download and install Git for Windows.

For Linux:

sudo apt-get install git

For Mac:

brew install git

Using HomeBrew

Create a Repository

Once Git is installed on your system, you are able to access it using the command line by typing ‘git’. If you have a clean folder, you can initialize a Git Repository by typing

git init

What does this do? It creates a ‘ .git ‘ folder in the folder where you typed the command. It’s a hidden folder so might not be able to view it.


Adding files to Repository

To add a file to repo, type

echo "Hello world" > README.txt

to create a file in the folder but its not yet added to git repo. To check the status you can use this command:

git status

Now once we have the file, we need to add it to staging area and making it visible to Git.

git add README.txt

If you want to remove this file from staging area you can use this command:

git reset README.txt

Now the next step once you add it to staging area is to commit it. You can commit using:

git commit -m " This is my first commit "

This will clean the staging area and will permanently store the edit you made in a record which you can check using:

git log


When you commit a file to Git, you are essentially committing it to a current branch. Git is helpful and will enable you to work on multiple, separate branches which represents forks of the Master branch. Git by default creates a branch called “master”. Now if you want to create a new branch called develop you can do it using

git branch develop

If you want to see the list of branches in a repository, you can do it using:

git branch

Push and Pull

In Git you most of the time commit locally first. This is one of the big advantages over SVN where all the commits had to be pushed directly to server. Hence you can work offline can do as many commits as you need and once your code is ready to push them to server so people accessing repo can have it. But before doing push and pull you need to create a Remote.


A remote repo is a clone of your repo which is present in another machine. If you have an existing repository, you can publish it on GitHub. The procedure involves creating a repository on the platform, through their web interface, then you add that repository as a remote, and you push your code there. To add remote type:

git remote add origin

Once you are done creating remote, you can now push your code to remote, using this syntax

git push <remote> <branch>

for example

git push origin master

Similar kind of syntax applies to pull as well.

git pull origin master


In both push and pull there is a problem to consider: if the remote contains changes incompatible with your set of commits, the operation will fail.

This happens when the remote contains changes subsequent to your latest pull, which affect lines of code you worked on as well.

In the case of push this is usually solved by pulling changes, analyzing the conflicts, and then making a new commit that solves them.

In the case of pull, your working copy will automatically be edited with the conflicting changes, and you need to solve them, and make a new commit so the code base now includes the problematic changes that were made on the remote.


Here is a small introduction to git, however there are a lot of commands and utility tools for Git which are available online, you just need to cherry pick and use them to suit your needs.


Thanks for dropping by !!! Feel free to comment to this post or you can send me an email at [email protected]