Getting started with Git

July 8th, 2019

Git is what is known as a Version Control System (VCS). It allows you to keep track of changes made to files as well as drastically improve working with other developers on shared codebases.

The first step to using Git is install it:


Once that is out of the way, we need to tell Git who you are (this step is needed for later commands)

$ git config --global “”
$ git config --global “Jordan Knott”

Another config value I would recommend setting is “core.editor”. It tells Git which text editor it should use when opening files. I use Vim, so I can tell Git to use it by running

$ git config --global core.editor “vim”

The --global flag means that the above config settings will be used for every repository (a codebase that git is tracking) rather than for just one.

Now, we can create a repository. For this primer, we’ll be using this [ GITHUB TAR LINK ] as the base for our repository. Just go to the above link, down the zip (or tar.gz file) then extract it somewhere. Once it’s been extracted, navigate to new folder in a terminal.

We can create the repository with the git init command. Go ahead and run it.

If you do ls -a, you should be able to see a new folder called .git. This is where snapshots of file changes are kept along with some other data. It’s what marks this folder as a repository.

There are a couple core commands in Git, the first of which is git status. It is the main tool to figure out what state files are in.

In Git, there are four states a file can be:

Untracked: Git doesn’t know nor care about this file Modified: Git knows about this file and know that has changed Staged: Git knows about the changes to this file and its current state will be stored in a snapshot on the next commit. Committed: Git has a snapshot of the file safely stored in Git

Since we have just created this Git repository, all of the files are untracked. Let’s verify this by running git status. It should show something like this:

The next core Git command is git add. It tells Git that you want to add the file (and it’s current contents) to what is called the staging area.

The staging area is a list of state changes that will be stored as a snapshot during the next commit (essentially a save).

The git add is also used to tell Git to start tracking files as well.

Let’s go ahead and add index.html by doing git add index.html

Next, run git status so we can see the new file state changes. It should look like this now:

If we add the --all (or -a) flag to the git add command, it will add all file changes to the staging area. Go ahead and do that now

$ git add --all

Then run the git status command: it should show all of the files in the staging area.

Now it’s time to make a snapshot of the current staging area! This is where git commit comes in.

A commit within Git contains both a snapshot about all of the file changes from the staging area as well as some information about the committer (the person making the commit, you!).

Let’s create a commit by running git commit.

It should open your default text editor (or the editor set in core.editor). The file it opens should have some content already added to it and will look something like this (I’m using Vim in the screenshot)

This is what is called the commit message. It’s a description of the commit you are about to make and should contain at minimal a simple message about what the commit does.

For my commit message, this is what I’ve written.

The first line of the commit message is what is shown in commands such as git log. It should be kept under 80 characters.

Once you’re done, go ahead and save the file then quit the text editor.

Now, you’ve created your first commit!