Hi! I am Sanjula, and in this guide I hope to teach you a little bit about Git including:

  • What Git is
  • Why learn Git
  • Setting configuration variables
  • Introduction to the help command in Git
  • How to convert an existing project into a local Git repository
  • Things to do before the first commit
  • How to add files to the staging area
  • How to remove files from the staging area
  • Making your first commit
  • How to clone a remote repository
  • View information about the remote repository
  • How to push your changes to the remote repository
  • How to create a branch for a specific feature or issue
  • Push the branch to the remote repository after committing
  • How to merge a branch
  • How to delete a branch

Let’s get started!

What is Git?

In straightforward terms, Git is an open-source distributed version control system.

Version control systems help any software team to manage changes to source code of a product or service over time. It keeps track of all the modifications to the source code in a database. If a critical mistake has been made to the source code, then the developers on a software team can rewind the source code to a version before the erroneous change was made. As a result, version control systems protects source code from disasters, human errors and unintended consequences (when a bug fix breaks another part of the application, for example).

So why learn Git?

Git is the most widely used version control system in the world today. It is a mature and actively maintained open source project originally developed by Linus Torvalds.

An astounding amount of software projects rely on Git for version control, including both commercial and open-source projects, especially using the git repository hosting service, GitHub, which is now owned by Microsoft. Hence, the importance of learning Git.

Prerequisite for this guide

Download and install git here

Check version of git

git --version
Figure-2: Git version

If the version number is returned, then it means that git is successfully installed on your computer.

Setting config values

Now we need to set the global configuration variables, which are very important, especially if you are working with other developers. The main advantage of this being it is easier to find out who has committed a certain code block, for example.

git config --global “Sanjula Madurapperuma”
git config --global “”
git config --list

Help Command

As you may notice, config is a verb that has been used frequently so far in this handbook and verbs can also be used as either a prefix or suffix with the help command. We can use the same example (the verb config) from above to explain these commands.

git help config
git config --help
Figure-3: Help Command

Both of the above commands perform the same action. Show the manual page for the verb specified. This will be useful to identify more advanced capabilities of git.

How to initialize a repository from existing code

If you have a local repository that you want to convert into a git project to start tracking it, then we can start by running the command below within the project directory.

git init
Figure-4: Git init

Done! Just like that you have converted your project into a local git repository. If you open up the project folder you will see that a new directory called .git has been created.

What to do before the first commit

Enter the following command to view untracked files:

git status
Figure-5: Git status

If there are files that you don’t want other people to see in the repository, such as files containing personal preferences or those of the IDE, then do the following:

touch .gitignore
Figure-6: Create .gitignore file

To specify which files are not to be added to the git repository, open up a text editor and view the .gitignore file, which can be edited like a normal text file. Now we can enter the following into the file, for example:


Wildcard characters can also be used. In this case, it has been used to specify not to add all files ending with the .java extension to the repository.

Figure-7: Editing in text editor

Now run git status again

Figure-8: After updating .gitignore

Now you can see that the files we excluded in the .gitignore file are no longer shown in the list of untracked files. The .gitignore file should be committed to the repository in order to maintain the same exclusions in all other places.

Adding files to the staging area

All this time we were in the working directory. The staging area is where we organize all the files that are tracked and have to be committed before pushing to the git repository. It is a file that stores what has to be included in the next commit.

If you want to add all the files that are currently untracked and you’ve changed to the staging area, then use the following command:

git add -A

If you want to add files individually, then we can give the file name after git add. For example,

git add .gitignore

Now if you type in git status, you will see that the .gitignore file is now in the staging area.

Figure-9: Staging area

Removing files from the staging area

To remove files individually from the staging area, type in the following (for example):

git reset

This will remove the file from the staging area. To see this change, type in git status again.

Figure-10: Removing file from staging area

If you want to remove all the files from the staging area, then run the following:

git reset

Now if we type in git status, we will see that all the files have been changed to untracked files.

Figure-11: Reset all files

Making the first commit

Now run the following to add all the files to the staging area to be committed.

git add -A

If you want, you can run git status to see all the files that will be committed.

To commit, type in the following.

git commit -m “Initial Commit”

“-m” specifies a message to be passed describing the commit. Since this is our first commit, we will say Initial Commit.

Figure-12: Initial Commit

As you can see, the files have been committed successfully.

If you run git status now, you will see that it says the working directory is clean because we have committed the files and haven’t modified any file since.

Figure-13: Working Tree after commit

If we run the following command:

git log

then we can see the commit that we just made, including the hash number of the commit.

Figure-14: Commit hash number

We are now successfully tracking the local project with git!

Cloning a remote repository

If we want to track an existing remote project with git, then we have to type in a command in the following format:

git clone <url> <where to clone>

For an example, I will be using the git repository at this link.

I will first move into the directory that I want to clone the project in, though you can specify this as shown above as well.

Go to the repository link given above and click on the “Clone or Download” button, then copy the link given there.

Then enter:

git clone
Figure-15: Cloning remote repository

Now we have cloned the repository successfully.

If we enter the following command, we will see all the files that are in the local directory now.

ls -la
Figure-16: List all files in directory

Viewing information about the remote repository

If you type in the following command:

git remote -v
Figure-17: Git remote -v

This command will list the locations where the local repository would fetch external commits from and push your commits to the remote repository.

If you were to type the command

git branch -a
Figure-18: List all git branches

This will list all the branches which are in the repository, both locally and remotely.

In order to demonstrate updating the remote repository, we will make some changes to the files in the repository we cloned.

Figure-19: Make changes to

Now that we’ve made a change to our code, the next action we have to make is to push these changes to the remote repository

Pushing changes to the remote repository

The following command will show all the changes that have been made to the files.

git diff
Figure-20: View changes to file

If we enter git status again, we can see that changes have been tracked and that has been modified.

Figure-21: View modified files

Now add them to the staging area

git add -A

Run git status again

Figure-22: Add files to staging area

Now we can see that is ready to be committed.

Then enter the commit command with a message

git commit -m “Updated hello function”
Figure-23: Commit message

Now we have to push the committed changes to the remote repository so other people have access to them.

Since the common case is that there are several developers working on a single project, we have to first pull any changes that have been done in the remote repository before pushing our changes to it to avoid conflicts.

Run the following command:

git pull origin master
Figure-24: Pull changes from remote repository

Since we are already up-to-date, we can now push our changes to the remote repository.

Now run the following:

git push origin master
Figure-25: Push changes to remote repository

We have successfully pushed our changes to the master branch of the remote repository!

Creating a branch for a feature or issue

So far we have been working on our master branch, but this is not how you should be working in git as a developer because the master branch should be a stable release of the project that you are working on. So for every feature or issue, it is usually the norm to create your own branch and then work off that branch.

The command to create a new branch called simple-greeting is as follows:

git branch simple-greeting

Now if you run

git branch

then you will see all the branches in the repository, and the current branch that you are in is highlighted with an asterisk on the left side.

Figure-26: git branch

If you want to switch to the branch that you just created, then type the following:

git checkout simple-greeting

Now if you type git branch you will see that you are now on the simple-greeting branch.

Now we have to make the changes in the project. We’ll switch to the project and define the greeting function.

Figure-27: Define the greeting function

Now we will repeat the process of committing these changes:

git status
Figure-28: See changes that are not staged
git add -A
git commit -m “Greeting Function”
Figure-29: Commit message for Greeting function

This commit will only change the files in the local branch simple-greeting and it has had no effect on the local master branch or remote repository yet.

Pushing branch to remote repository after committing

Enter the following command:

git push -u origin simple-greeting

where origin is the name of the repository and simple-greeting is the branch that we want to push to.

Figure-30: Push branch to remote repository

Now we have pushed the simple-greeting branch to the remote repository. If you type:

git branch -a
Figure-31: simple-greeting Branch in remote repository

We can see that, in our remote repository we now have the simple-greeting branch. Why do we need to push the branch to the remote repository? Because in some companies that’s where they run their unit testing and various others to make sure the code runs well before it’s merged with the master branch.

Given that all the testing has come out well (we won’t go into detail here), we can now merge the branch simple-greeting with master branch.

Merging a branch

First, we have to checkout into the local master branch

git checkout master
Figure-32: Checkout to master branch

Pull all the changes in the remote master branch:

git pull origin master
Figure-33: Pull changes from remote repository

We’ll now see the branches we have merged in so far:

git branch —-merged
Figure-34: Display merged branches

simple-greeting branch will not appear here because we haven’t merged it yet.

To merge simple-greeting with master, enter:

git merge simple-greeting

(Keep note that we are in the master branch right now)

Figure-35: Merge simple-greeting branch

Now that it’s been merged, we can push the changes to the remote repository master branch.

git push origin master
Figure-36: Push to remote master branch

Now the changes have been pushed to the master branch in the remote repository.

Deleting a branch

Since the feature has now been deployed, we can delete the simple-greeting branch. To double check the merge done in the previous section, we can run:

git branch --merged
Figure-37: Display merged branches

If simple-greeting shows up here, then that means that we have merged all the changes and that the branch can now be discarded.

git branch -d simple-greeting
Figure-38: Delete local branch simple-greeting

Now the branch has been deleted locally.

But since we pushed the branch to the remote repository it is still there in the remote repository. This can be seen by running:

git branch -a
Figure-39: Display all branches

To remove the branch from the remote repository, enter:

git push origin --delete simple-greeting
Figure-40: Delete remote branch simple-greeting

If we re-run

git branch -a
Figure-41: Display all branches

we can see that the branch has now been deleted from the remote repository as well.

Congratulations!!! You are now a master in basic but critical Git commands!

For reference or use of this tutorial, here is the public GitHub Repository Link

In the meantime, give as many claps as you like to this article if you liked it, comment down below for any concerns. Also please checkout my profile at LinkedIn and follow me on Twitter!