Git Part 2: Our first commit

18th June 2020

In my last post we looked at version control, and why it’s worth using it for all your projects. Now it’s time to put that into practice and see how we can use git in a real project. We’ll be looking at a couple of the most basic features for working alone (and locally).


There are a lot of programs that will simplify things for you. Code editors such as VS Code have git support built in, and others such as Sourcetree will let you see a visual representation of what’s going on. I would strongly recommend both.

For the purpose of this tutorial I’m going to be using only the terminal commands for git. Although it’s often easier to stick with GUI tools, I think there’s value to having at least some understanding of what’s going on behind the scenes.

The programs mentioned above will let you do everything mentioned visually, but behind the scenes they’ll be running these same commands.


We’re going to start with an empty directory, which we will use for our project.


To start using git we have to initialise it inside this folder. This tells git that we want to create a new repository here.

git init

Behind the scenes: If you have hidden folders visible you’ll notice that this creates a folder called .git within our directory. This hidden folder is where everything related to our version control is stored.

We now have a git repo!

Tracking a change

Let’s create a file called index.txt. We’re going to focus on this file for now, although git works with multiple files/folders within our project.

└── index.txt

We can now run the useful command git status to see how this affects our git repository.

git status
On branch master

No commits yet

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

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

Although our file exists, it isn’t being tracked yet, so we need to tell git to include it.

Why not track by default? Git tracks changes, and creating a new file is just another change. By allowing us to choose which changes we want to include in a commit we have a lot more flexibility.

Git helpfully gives us a tip on how we can track our file. We can use git add to track a file’s changes ready to commit them.

git add index.txt

Now if we check the status we can see how things have changed.

git status
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   index.txt

Git is now tracking the creation of index.txt!

Committing our change

Now our file is tracked we need to create a commit. This is a snapshot of the project at a certain point in time. That way we can compare any future changes to where we are now. We do this using the git commit command.

To make things easier for ourselves we’ll need to add a message using the -m argument. This lets us label our commit so we know what it is later.

git commit -m "Create index file"
[master (root-commit) f3df944] Create index file
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 index.txt

And there we have it! We now have our first ever commit!

Making an update

If we run git commit again we can see the following:

git status
On branch master
nothing to commit, working tree clean

What this means is that everything is tracked by git, and there are no changes to worry about. Which makes sense, we’ve just committed our only change after all.

So let’s make a change.

If we add the line “Git is fun” into our file and save, then we get a different result from git status.

git status
On branch master
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:   index.txt

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

Because we’re now tracking index.txt, git helpfully lets us know that we have a change: index.txt has been modified.

We can use another helpful command to see how it’s been modified.

git diff
diff --git a/index.txt b/index.txt
index e69de29..949d7bd 100644
--- a/index.txt
+++ b/index.txt
@@ -0,0 +1 @@
+Git is fun
\ No newline at end of file

git diff allows us to see the difference between different versions of the file. In this case, we can see that a new line has been added: “Git is fun”.

Now we have the choice of committing our change, or reverting back to our commit. Let’s get rid of it for now. Git helpfully gave us those options in our git status, so we can use git restore.

git restore index.txt

And now:

git status
On branch master
nothing to commit, working tree clean

Our changes are gone.

What if I want to save my changes (but keep them separate)?

In Part 3, we’ll be exploring one of git’s most important and powerful features: Branches.