Git Commands: The 13 You Must Know, In Order

10 min read

There are challenging aspects of Git you might face while learning it, but most of the time you’ll be using a relatively small number of commands. So, you only need to master the most often used Git commands to get started with the tool.

We’ll cover the commands in the order you’d typically use them, working with the same repository throughout the post.

I’ll assume you have Git installed and some familiarity with the command line.

Most commands in Git have many options and parameters; for brevity, we’ll focus on the most typical usage of each command.

Git Commands to Start Work in a New Repository

Let’s start by showing you how to create a new repo to start working.

Create a New Repository With

To create a repository, you’d typically create a new folder, navigate to it, and then use the git init command. Here’s an example:

mkdir demo # create a new folder

cd demo # navigate to the new folder

git init # start the new repository

Initialized empty Git repository in /home/username/repos/demo/.git/

Configure Your Identity With

When you commit your work with Git, your identity—name and email—is registered in the commit object. Using the git config command, you can configure your identity—among many other things—on a repository or global level.

Configure your identity for the repository you’ve just created:

# configuring your name

git config user.name "Your Name"

# configuring your email

git config user.email user@emailprovider.com

After you’re done, run git config user.name and git config user.email—without the arguments—to verify the configuration was successful.

Git Commands to Track Your Changes

Now that you have a functional repository, it’s time to do some work with it.

Start Tracking Files With

In Git, new files aren’t automatically versioned. So, when you create new files, you need to tell Git to track them so it can track their revisions. Start by creating a new file:

echo hello world > file

If you run the command git status, Git will say you have an untracked file:

On branch main

No commits yet

Untracked files:

 (use "git add <file>..." to include in what will be committed)

        file

nothing added to commit but untracked files present (use "git add" to track)

What the message above means is that you don’t have any changes to be included in the next commit. But you do have an unversioned—untracked—file, and you can start tracking it by using the git add command:

git add file

The command git status now displays a different result:

On branch master

No commits yet

Changes to be committed:

(use "git rm --cached <file>..." to unstage)

        new file:   file

Save Your Changes With

After your file is tracked, you’re ready to commit. “To commit” means to save your changes, creating a named point you can return to—i.e., a commit object.

Every time you commit your work, you must supply a commit message that explains why that change was needed. To supply a commit message, you can either use the -m parameter or wait for Git to open your text editor.

Let’s go with the first option:

git commit -m "Add text file"

You can now use the command git log to see your commit history:

git log

commit 5243b8aa962425fc81c13a7d5d7ecb37bf52b271 (HEAD -> main)

Author: Your Name <user@emailprovider.com>

Date:   Tue Jun 8 14:20:53 2021 -0300

     Add text file

Add Changes to Be Committed With

Similar to new files, changes to existing files aren’t automatically versioned. To ensure they are included in the next commit, you need to add them to this preparation area we call stage or index.

To do that, we use the git add command, which is multipurpose.

Start by changing the existing file:

echo another line >> file

Then run git status, and Git will show you this:

On branch main

Changes not staged for commit:

  (use "git add <file>..." to update what will be committed)

  (use "git restore <file>..." to discard changes in working directory)

        modified:   file

 no changes added to commit (use "git add" and/or "git commit -a")

Now, just do as Git says and add the change:

git add file

You can now commit normally:

git commit -m “Add new line to file”

What if you had several changes to commit? In that case, it would be tedious to git add each different file. Thankfully, you don’t have to do that. You can simply use git add . to stage all of the current changes in one go—if there are untracked files, they get tracked as well.

Alternatively, you can skip that step and go directly to git commit along with the -a parameter—”a” for all. That stages all existing changes and commits them in a single step, but it doesn’t track untracked files.

Git Commands to Manage Branches

Git’s powerful branching capabilities are one of its selling points. Even though that’s not exactly how things work under the hood, you can think of branches as independent copies of your project where you’re free to experiment without messing with the main line of work.

Create a Branch With

To create a new branch, you simply use the git branch command, followed by a name for the new branch:

git branch exp

That’s it. If you now run git branch without argument, you’ll see the list of existing branches:

git branch

  exp

* main

Switch to a Branch With

After creating a branch, you’ll typically want to switch to that branch to work on it. To switch to a branch, there are two options: git checkout and git switch.

The git checkout command actually does many different things. As a result, recent versions of Git introduced the git switch command, which is solely dedicated to switching branches. Look at these examples:

git checkout exp # switching to the 'exp' branch, using the older option

git switch main  # switching back to the 'main' branch, using the newer 'switch' command

Creating a branch and immediately switching to it is so common they created a shortcut for it:

git checkout -b test # creating a branch named 'test' and switching to it

git switch -c test2 # creating a branch named 'test2' and switching to it

Merge Branches With

Branching is just the start; eventually, you’ll want to merge back, incorporating the changes you’ve made in that branch into the main development line. You use the git merge command for that.

Start by creating a new branch and switching to it:

git switch -c merging-demo

Now, let’s add a few commits:

echo new file > file2 && git add file2 && git commit -m "Add a second file"

echo new file > file3 && git add file3 && git commit -m "Add a third file"

echo more content >> file && git commit -am "Edit first file"

Your new branch now has three new commits, which you can verify using git log. Now, go back to main using git switch main. If you now run git log, you won’t see the three commits.

To incorporate those changes, you’ll need to merge the merging-demo branch into the current one:

git merge merging-demo

Now, if you use git status you’ll see the new commits have been incorporated. 

Bear in mind that this is just the most basic form of merging, called a fast-forward merge. Merging can get more complicated than that. 

Learn More About Branches

If you want to learn more about branches in Git, check out the following links:

Git Commands to Undo Things

Going back and undoing things is a common task when using a version control system. Git offers many ways to handle that. We’ll cover some of the main ones now.

Cleaning Untracked Files With

Let’s say you have new, untracked files and you want to get rid of them. You could simply delete them, but Git offers you a dedicated command to do that: git clean.

Start by creating a new file:

echo hello world > file4

Now, if you run git status, you’ll see you have an untracked file. You can now use the following command to clean it:

git clean -i

The -i parameter stands for interactive. After running the command, you’ll see an image like the one below:

You can now choose an option, either by number or by using the selected letter for each option. Since we want to clean, press 1 or c and you’ll see a message saying the file was removed. And you can, of course, check that by yourself.

Warning: Make sure you know what you’re doing when using this command because there’s usually no way to recover the information you erase with it.

Reverting a Commit With

Rewriting public history is a big no-no in Git. But what if you need to “nuke” a commit that is already public?

A solution is to create a new commit that “negates” the one you want to erase. The unwanted commit remains there, but its changes are effectively undone. You do that with git revert.

Start by adding a new commit:

echo a line i want to erase >> file && git commit -am "Edit first file again"

To revert the commit, you need its hash. Use the git log command to find that. Then run the following command, replacing the hash with the actual one you’ve recovered:

git revert 00b236f

After you run the command, Git will open your text editor so you can edit a message for the new commit that will be created. As soon as you save and close, the command will be completed:

a82549a Revert "Edit first file again"

00b236f Edit first file again

8a2b122 Edit first file

Two more things to keep in mind before we move on:

  • Because we wanted to remove the most recent commit, we could’ve used HEAD instead of the commit hash.

  • Reverting commits can result in conflicts if you revert a past commit upon which later commits depend.

Learn More About Undoing Things

If you want to learn more about how to go back in Git, check out the following article: Git Revert Commit: Everything to Know About Going Back

Git: Get Good Quickly by Mastering the Key Commands

The “surface area” of Git commands can feel daunting. Git has many commands, and most of them offer a plethora of options and parameters.

The good news is that you don’t need to learn all of them. Acquiring a mastery of the main commands you’ll use most often will take you further than trying to learn every command Git offers.

This post was written by Carlos Schults. Carlos is a consultant and software engineer with experience in desktop, web, and mobile development. Though his primary language is C#, he has experience with a number of languages and platforms. His main interests include automated testing, version control, and code quality.

Stay up to date

We'll never share your email address and you can opt out at any time, we promise.