Git is a version control system similar to how ‘track changes’ works in word processing programs. The main difference between git and these programs is that git can track changes to entire directories and not just a single file.
The typical workflow with a ‘track changes’ program involves emailing a draft to collaborators so that collaborators can track their changes before emailing it back to the original author. This may work well when the number of collaborators is very few but quickly becomes unstable and problematic in larger teams. Git can also be compared to cloud synchronization services like Dropbox but you get a more fine-tuned version controlled history to revert back to and the ability for collaborators to simultaneously edit the same file. Depending on how we use git, the amount of storage space is not as limited as in the case of cloud providers. Git is a distributed version control system and succeeds centralized version control systems like SVN & CVS. Centralized systems required all users to connect to a centralized server before editing a file. As a distributed system each user has all the code as well as the revision history on the computer they are working on. This not only serves as a backup layer since only one computer is needed to repopulate the backup files and revision history but also allows multiple users on multiple users on multiple computers to work independently.

In one of our previous articles, we’ve covered how to install the git version control system and also setup git initial configuration. In this article, we will demonstrate how we would create our first git repository on our system. We will be using a Centos 7 machine with git version 1.8 installed.


Step 1: Verify git is installed and check global parameters
Before we create a repository we must first check that git is actually installed on the system followed by which we will check that our initial parameters like username and email address have been populated. We’ll use the rpm command with the -q (query) option followed by the keyword git to verify that we have git installed on our system.

[sahil@linuxnix ~]$ rpm -q git
[sahil@linuxnix ~]$

Now that we have verified that git is indeed installed on the system that we are working with let’s now check if our global parameters have been populated. We display them using the ‘git config –global –list’ command as well as look inside the .gitconfig file in the users’ home directory.

[sahil@linuxnix ~]$ git config --global --list Suri
[sahil@linuxnix ~]$
[sahil@linuxnix ~]$ cat ~/.gitconfig
name = Sahil Suri
email =
editor = vim

Step 2: Create a directory named git
When we start working with git, it is a good practice to have a directory named git in your home directory. We’ll now create a directory named git within the users’ home directory.

[sahil@linuxnix ~]$ mkdir git
[sahil@linuxnix ~]$ cd git
[sahil@linuxnix git]$ pwd
[sahil@linuxnix git]$ ls -ld .
drwxrwxr-x 2 sahil sahil 6 Mar 4 22:39 .
[sahil@linuxnix git]$

Now that we have created a directory named git, we’ll keep all our git related projects inside it.

Step 3: Create a folder for your repository
Within our git directory, we’ll create a directory named my_first_repo. This directory will be the placeholder for our first git repository.

[sahil@linuxnix git]$ mkdir my_first_repo
[sahil@linuxnix git]$ cd my_first_repo/
[sahil@linuxnix my_first_repo]$ pwd
[sahil@linuxnix my_first_repo]$ ls -ld .
drwxrwxr-x 2 sahil sahil 6 Mar 4 22:45 .
[sahil@linuxnix my_first_repo]$

Step 4: Create the git repository using ‘git init’ command
There are two ways via which we could work with git repositories. One way is to use a folder or directory that already has some content that we want to track and the other is initialize our repository within an empty folder and then proceed from there. For the purpose of this demonstration, we’ve created a new directory and will initialize or create our git repository inside it. The way we initialize or create a git repository within a directory is by executing the command ‘git init’ from within the directory.

[sahil@linuxnix my_first_repo]$ git init
Initialized empty Git repository in /home/sahil/git/my_first_repo/.git/
[sahil@linuxnix my_first_repo]$

The ‘git init’ command tells git that we want to track the changes made to the content that resides within this directory. This tracking will include any sub-directories that we create within this directory and the files that we create within those sub-directories. Therefore, we should be careful while running the ‘git init’ command and make sure that we are in the correct location before we execute the ‘git init’ command. We could run the ‘git init’ command within a sub-directory that resides within an already initialized git repository folder. This structure is referred to as a git sub-tree or git sub-module.

Executing the ‘git init’ commands creates a hidden .git directory within the current working directory.

[sahil@linuxnix my_first_repo]$ ls -a
. .. .git
[sahil@linuxnix my_first_repo]$

This .git directory will contain all the version control information that git will be using.

Step 5: Check the status of the repository
The command ‘git status’ displays the status of the git repository that we are in and is a command that git users make use of very frequently.

[sahil@linuxnix my_first_repo]$ git status
# On branch master
# Initial commit
nothing to commit (create/copy files and use "git add" to track)

This gives us some information about the present state of the git repository we are in. We will be explaining the terms mentioned in the above output in greater detail in our future articles.



In this article, we provided some insight into why we should use git and how it’s more advantageous to use git over centralized version control systems. We then demonstrated a step by step procedure to create our first git repository. We hope that you’ve found this article to be useful and we look forward towards your feedback.

The following two tabs change content below.

Sahil Suri

He started his career in IT in 2011 as a system administrator. He has since worked with HP-UX, Solaris and Linux operating systems along with exposure to high availability and virtualization solutions. He has a keen interest in shell, Python and Perl scripting and is learning the ropes on AWS cloud, DevOps tools, and methodologies. He enjoys sharing the knowledge he's gained over the years with the rest of the community.