22 Essential Git Commands

Git has become the quintessential version control system. The rise of Git’s popularity can be attributed to its speed, agility and versatility. Whether you are a freelancing web developer or a software designer for enterprise-level applications, you can benefit from using Git. It helps you keep track of your files through systematic versioning. Git makes it easier to roll-back to older versions of code or create new branches to experiment on the current codebase. Also, Git is a distributed version control system which means you don’t have to always connect to a central server to get your work done.Below are the essential Git commands that will help in your day-to-day tasks. The simple examples will give you an understanding of the commands, so you can easily remember the syntax when you need to use them.

1. git add

The git add command lets you start tracking files and folders for your Git repository and moves them to the staging area. You’ll have to use the git commit command to make them permanent on your historical snapshots.

Using the command is easy. You can choose to add files and folders individually or use Linux type asterisk (*) glob operator to add them in groups.

Let’s take the example below:

Suppose, in the above case, we have already added the ReadMe.txt. But the rest of the files haven’t been added.

Let’s check the status:

The files and folders are in red which means they are not being tracked. We can add them using:

If we check the status now:

The git add command has added the files to the staging area. Files are kept in the staging area before making them permanent through the commit process.

2. git branch

On Git, branching is easy. In other version control systems, it was an expensive operation. But Git algorithms are optimized for branching. So you can use the git branch command whenever you want to create a separate line of development without worrying about performance.

Let’s look at the following example.

Notice we are ‘On branch master’. When you create a new project, you’ll end up in branch master. You can also use the git branch -a command to find out on which branch you are on:

The above is telling you that there is only one branch called ‘master’ and the asterisk (*) means you are on that branch.

Let’s create a new branch called ‘testing’:

Now we can check the branches again:

Even though, we are still on the ‘master’ branch, we can also see the new ‘testing’ branch that was created. The ‘testing’ branch is a replica of the ‘master’ branch.

3. git checkout

The git checkout command takes you to a branch, so you can work on the resources in there. You can think of branches as rivers and streams. With a branch, you create a new stream. With the checkout command, you move into that stream.

Let’s checkout the ‘testing’ branch from the previous example:

Now let’s check the status and the branches again:

You can see from the git branch -a command that we have moved to the testing branch.

4. git clone

The git clone command allows you to make a copy of any Git repository. As soon as you clone a repository, the new cloned folder will start keeping track of changes locally. Because Git is distributed, a clone is a fully autonomous Git repository.

In order to show how cloning works, let’s create a new repository:

In the above example, we have created Git repository called ‘myproject’ inside ‘dir1’ folder. Suppose, this is our main repository. Now we want to make a copy of it and work elsewhere.

Let’s create a directory called ‘dir2’ and clone the ‘myproject’ repository. We are using the git clone <dir> to clone ‘myproject’:

The git clone command works with a URL too.

Also, you can change the name of the clone by specifying it after the Git repository address:

5. git commit

The git commit command is run after the git add command. In our git add example, we had added the files for tracking, but we hadn’t committed it to the Git repository. Tracking stays local until a commit is made. When you commit the changes, they become part of the permanent record.

Below we are running the git commit -m <comment> command:

If you don’t use the -m option to put a comment, Git will open your default text editor and ask for it. Comments are considered good version control practice. So always put meaningful comments in your commit.

6. git config

The git config command lets you setup various options for your git repository. For example, you can use the git config —global <key> <value> command to get and set your user.name and user.email.

Here’s how you can set the values:

Here’s how you can check the values:

7. git diff

The git diff command helps you see the differences between files and folders. If you are making changes in a file, it’s a useful tool to quickly evaluate the changes you made.

Let’s suppose we start our work with a ReadMe.txt file with two lines. Then we get rid of the second line and add a third line.

Now if we run the diff command it will show the differences between the committed version and the local changed version in the staging area. Here’s how it will look:

Line 1 is unchanged (white), Line 2 removed (red) and Line 3 added (green).
You can use the diff command to also find differences between particular commits.

8. git fetch

The git fetch command gets the latest resources from the specified origin.

Let’s look at an example. Supposed you have the following condition:

The folder ‘dir2/myproject’ is cloned from ‘dir1/myproject’. Now if someone committed changes to ‘dir1/myproject’, you can get those changes like this from inside ‘dir2/myproject’:

It’s important to remember that git fetch command doesn’t merge the changes. For automatic fetch and merge, use the git pull command. Then you might be wondering why use this command in the first place. There might be advanced Git options where you get all the changes from your origin server and then only apply changes selectively to certain files. The git fetch command allows you to achieve this. However, it’s an advanced topic that you can find in the git fetch documentation.

9. git grep

The git grep command allows you to search your Git tree for information. Here is example of searching the word ‘Line’ in our git repository. The -n or —-line-number option shows line numbers where Git finds a match:

You can run a similar search for number of times the match is there with -c or —-count option:

The reason for using git grep over Linux grep is that git grep is faster for git repositories.

10. git log

The git log command shows you the commit history.

You can also use the —-oneline option to see an abbreviated version. The abbreviated version is easier to follow.

11. git merge

The git merge command merges branches.

Let’s create a new repository with ‘main’ and then create a ‘test’ branch.

In the ‘test’ branch, let’s make some changes:

We have added two files to the test.

We see from the above, that File1.txt and File2.txt exists in ‘test’ branch, but not in ‘master’.

Let’s merge now.

Now we have ‘File1.txt’ and ‘File2.txt’ in ‘master’ branch too.

Note: Think of merging as a pull operation. You have to be in the branch you want to merge into. In this case, you are in the ‘master’ branch pulling the changes from the ‘test’ branch.

12. git mv

The git mv is a short cut command to run git add and git rm commands. It can be used to rename files.

Here is an example:

13. git pull

The git pull command is a lot like the git fetch, except the merge happens automatically.

Here is an example of running git pull origin like the git fetch one (we are running a pull request from the clone to get changes from the original Git repository):

You can see that changes have been downloaded from the origin and merged into the clone.

14. git push

The git push command is used to push changes to remote repositories. Here is an example of running the push command:

The git push origin master command is sending changes to the ‘master’ branch of the origin (the Git repository you cloned) from the ‘master’ branch of the cloned repository. Visually, the push looks like this:

15. git rebase

The git rebase command helps you change the base of the branches. In a general merge, something like this happens:

The test branch has been merged into the ‘master’ branch to create a new commit.

In a rebase, this is what happens:

The changes from E and F changelist is recalculated and latched at the end of the master branch. Rebasing helps simplify the branches.

Let’s suppose we have this situation in the ‘master’ branch:

And a feature branch:

If we rebase, we get git rebase master:

First, rewinding head to replay your work on top of it…

Now if you go to both the ’master’ and the ’feature’ branch, you’ll see the same logs:

Rebasing has squashed them together.

Note: Never use rebasing in public repositories as developers will run into major merge issues.

16. git remote

The git remote command allows you to set a remote server for your repository. In a cloning situation, the source repository automatically becomes the remote.

For example:

The above is showing that the remote server for ‘test’ is another folder called ‘myproject’. The reason is that ‘test’ was cloned for my project.

But the remote server doesn’t need to be local. You can have something like this with a URL:

You can set up a git remote repository using the command git remote add <shortname> <url>:

This will connect your repo to the origin so you can fetch and push.

17. git reset

The git reset allows you to unstage added files.

Let’s say you added the file ‘test.txt’ to your repository:

However, you decide you don’t want to track ‘test.txt’ anymore. You can use the git reset Head <file> command to unstage the file:

If you check the status, the file is again untracked:

The file ‘test.txt’ is no longer tracked.

18. git revert

The git revert command lets you reverse changes using the commit hash number.

We created a ‘MyFile.txt’ and committed two changes, so the file has the lines ’Test 1′ and ‘Test 2’. But we decided that we don’t want the second commit. So we found the commit hash (a976e9c) for it. We can use the git revert <commit hash> to get rid of the commit:

We see that there was a new commit hash created that reverted the ‘Test 2′ line commit. The file only has the ’Test 1’ line now.

19. git rm

The git rm command sets up files for future deletes. It puts the files-to-be-deleted in the staging area.

You have to commit the changes for the delete to take effect.

20. git stash

The git stash command allows you to temporarily abandon work that you are not ready to commit yet.
Suppose you are working in a repository with the following files:

In the middle of renaming and updating ‘John.txt’ to ‘ProjectFile1.txt’, you receive a request to change something in the project. But you are not ready to submit ‘ProjectFile1.txt’. So you stash it.

Saved working directory and index state WIP on master: f0b5a01 Init John and Mary

HEAD is now at f0b5a01 Init John and Mary

Your local work environment is back to where you were before making your project-based changes. After, attending to the interruption, instead of going back to ‘John.txt’, you decide to work on the ‘Mary.txt’ file now:

You get interrupted again and you stash your new work on ‘Mary.txt’:

After the interruption work is done, you check the stash list:

You have two work-in-progress (WIP) in the stash. Firs time you pop the stash, you get the latest ‘Mary.txt’ changes:

Second time you pop the stash, you get the ‘John.txt’-related changes:

And you have your work-in-progress ‘ProjectFile1.txt’ and ‘ProjectFile2.txt’ back.

So the git stash command helps you stash your work so you can get back to it later.

21. git status

The git status command displays the difference between current files and the HEAD commit.

Here is an example:

It’s showing that ‘File2.txt’ is being renamed to ‘File3.txt’ which is ready for commit, but the modifications in ‘File1.txt’ isn’t in the staging area yet.

So, we add everything:

Now when we check status:

We see all the changes are ready for commit.

22. git tag

The git tag command helps you to create tags for your important historical points. It is generally used to set up version numbers.

The git tag command will show you the current available tags:

You can tag with the command format git tag <TAG>:

In order to see what’s in the tag, you can use git show command:

You can also tag using a commit hash and the command format git tag <TAG> <commit_hash>:

In Conclusion

For any command, you can use git <command> -h to get more info.

Further Study

• https://git-scm.com/docs