Basic Git commands you need to know

The usage of Git as a primary Source Code Control is ever increasing and with Microsoft purchasing GitHub this is only set to increase.

Personally I have been using Git and Github for a few years now, and it has become my number one choice in Source Code Repository and Version Control System (VCS). Compared to others that I regularly have to deal with in the Enterprise Software Development landscape, it is far less clunky and for the most part far easier to use.

Although I would be the first to admit, it can be a bit intimidating to use, when you’re coming from the IDE based version control systems.

If you want a guide on how to get started and understand the basic Git commands you need to know then this post is for you!

The tool a software developer will probably use the most throughout their day will be a version control system. In some respects you will probably use it as frequently as a text editor or an IDE (Integrated Development Environment).

Gaining a competent level of understanding of how to use a version control system will help your career and future progression. It will also save your bacon when you need it most!

What is Git ?

Git is a distributed version control system for managing source code, which helps developers to manage and track changes to files. Using Git developers can quickly and easily follow and examine the history and changes made to a file of source code to understand the changes made.

When working on a software development team, this is become an essential practice, with multiple team members making changes and additions to source code files on a daily basis. The ability to go back in time, to learn about how a file has changed, who made the changes and why, is crucial to understanding how a bug or unintended behaviour has crept into a file.

Git also helps developers by preventing unintentional overwrite by any developer on a team who may be working on an older version of a file.

A version control system like Git helps developers too:

  • Keep track of code history
  • Collaborate on code as a team
  • See who made which changes
  • Deploy to staging or production

Why Learn Terminal Git Commands

Many developers are starting to drift away from the cumbersome do it all for you, point and click Integrated Development Environments (IDE) and starting to make use of lightweight Text Editors like Visual Studio Code, Sublime Text, Atom and myriad of others. These tools are great and can really be a boost to productivity. The downside is many of them don’t necessarily have a direct connection or plugin to a version control system and a lot of the interaction can boil down to using a terminal window.

I came across one of those scenarios the other day when a developer on a team I was working with on a project had not used Git via the command line and didn’t really know how or where to get started. However, after just spending 5 minutes explaining the basic commands and how and when to use them my colleague was able to get up and running with Git really quickly and now it has become his favourite VCS. He also made the remark that he now feels liberated from depending on an IDE to submit changes to a repository.

Another major plus, is the commands and approach to interacting with Git are the same whichever platform you choose to work on. Which from my experience is not always the case with other VCS.

Although the Git does have a extensive documentation available , it can be somewhat overwhelming and intimidating. It may also be a case of a little too much information for most new starters.

I’ll attempt to highlight the most basic commands you need to know to get started, and what you will most likely use on a day-to-day basis. For a broader understanding of Git I recommend Understanding Git Conceptually

Common Git terms

There are a number of common terms and words developers will use when talking about git repositories and working with git. it’s important to understand and remember these,

  • Repository – a container that tracks the changes to your project files.
  • Working Tree – Consists of files that you are currently working on. You can think of a working tree as a file system where you can view and modify files.
  • Index – a snapshot of the content of the working tree, and it is this snapshot that is taken as the contents of the next commit. Staging area where commits are prepared

Common Git commands developers should know

Although mastering git in its entirety, like most things in software development, is an art form, and for the most part, at least 80% of what you’ll learn will more than likely not be used in your regular day-to-day development task.

The below is a list of the most common git commands I predominantly use on a daily basis, which I believe are the essentials for most developers to learn and master.

git init

To create a new empty git repository or to reinitialize an existing one you simply need to navigate to your target directory eg. cd code and then git init

This command essentially creates a hidden .git directory with a number of subfolders objects, refs/heads , refs/tags.

if you execute git init on an existing git repository, it won’t overwrite any settings or details. it will only pick up any newly added templates or move a repository.

There are a few options you can use, which are essential -- switches to enable more advanced features.

Check out the Git Init Documentation further details.

For the most part, the average developer starting a new project isgit init more than enough.

git status

Once you’re created files in your folder and you want a quick review of what files have been added, modified or deleted in your folder as compared to you Git Repository. You can use git status.

This will show the working tree status, which is essentially the differences between the index file and the current HEAD. This provides a list of files that can add to git repository.

git clone

git clone is the command you’ll use to target an existing repository and create a clone, or copy of the target repository on your local machine.

Git’s collaboration model is based on repository-to-repository interaction, this means that you push or pull commits from one repository to another.

The original git repository you want to clone can be located on the local filesystem or on remote machine accessible supported protocols (https, ssh) i.e. GitHub, BitBucket or your enterprise Git version control repository.

git add

During the course of your development, you will undoubtedly be adding, modifying and deleting files ass you go. At some point you will need to add them to your repository, this is where the git add command comes in handy.

The git add command adds file contents to your index, by adding the content found to your working tree. It typically add the existing paths as whole, but there are options you can use to customise this behaviour.

When first starting out with git, you will enevitably first see the short hand command git add ., which basically enables developers to add all files with current changes and additions to the index.

Use git add . with caution often it could incur some unintended consequences

Ideally, you should become a little more verbose when adding files to your index, I typically add files on a one by one basis, using

filepath is the absolute or relative path to a file to the current working directory.

There two additional options you should become familiar with:

-A – stage files new, modified or deleted
-u stage only files modified or deleted files

git commit

The commit command is used to save your changes to the local repository.

A commit is not automatically transferred to the remote server. Using git commit only saves a new commit object in the local Git repository.

-m [message]
Sets the commit’s message, to help provide a concise description that helps your teammates understand what and why changes were made to a file.

Includes all changed files to a commit.

new or untracked files are not included

Rewrites the very last commit with any currently staged changes and/or a new commit message. Git will rewrite the last commit and effectively replace it with the amended one.

rewriting of commits should only be performed on commits that have not been pushed to a remote repository

Developers will also make use of a common shorthand for commit files git commit -am "changes to homepage", but overuse of this can lead to some undesirable outcomes on larger projects.

git push

Once you’ve committed your changes, you will often need to send them to your team repository, often called the remote, git push isd used to to updates remote refs using local refs, while sending objects necessary to complete the given refs.

git pull

The git pull command is used to fetch and download content from a remote repository and immediately update the local repository to match that content. Merging remote upstream changes into your local repository is a common task in Git-based collaboration workflows.

The git pull command is actually a combination of two other commands, git fetch followed by git merge.

In the first stage of operation, git pull will execute a git fetch scoped to the local branch that HEAD is pointed at. Once the content is downloaded, git pull will enter a merge workflow. A new merge commit will be created and the HEAD updated to point at the new commit.

git checkout

A checkout is an act of switching between different versions of a target entity.

The git checkout command operates upon three distinct entities:

  • files
  • commits
  • branches

In addition to the definition of “checkout” the phrase “checking out” is commonly used to imply the act of executing the git checkout command.

The git checkout command lets you navigate between the branches created by git branch. Checking out a branch updates the files in the working directory to match the version stored in that branch, and it tells Git to record all new commits on that branch. Think of it as a way to select which line of development you’re working on.


Git is a powerful version control system, which is steadily becoming the defacto standard for software development teams. GIt  has many commands and can be overwhelming for developers who are new to it to learn. The above guide has covered a majority of the commands developers will most commonly use on a day-to-day basis.

Gary Woodfine

Freelance Full Stack Developer at
Helps businesses by improving their technical proficiencies and eliminating waste from the software development pipelines.

A unique background as business owner, marketing, software development and business development ensures that he can offer the optimum business consultancy services across a wide spectrum of business challenges.