Lesson Tuesday

Git is a version control system for tracking changes in our code. We have to use tools like Git while we code to periodically take snapshots of our projects. By taking a snapshot of our project we can preserve the state of the project in that particular point in time. We continue to take snapshots as we work. Older snapshots are kept and the collection of snapshots represents our project history. The benefits of doing this include but are not limited to:

  1. If we really mess something up in our code, we can revert back to a previous snapshot when the project was working.
  2. We can demonstrate we are making progress on a project. Our project’s history is proof of work.
  3. Each snapshot can be authored meaning we retain credit for past work even if someone else takes over the project.
  4. We can preserve unused code we may want later.

Git also works with GitHub, which will be your coding portfolio when job seeking. The work you do now while learning how to code will be tracked by *Git *and all your hard work will be reflected in your GitHub account.

For these reasons, we need to take a pause from learning about code and shift to learning about Git. Afterwards, we will integrate Git into our regular workflow.


Learning Git is difficult and it likely will feel very convoluted at first. We want to give you context for what is happening with Git while doing our best to not weigh you down with unnecessary details.

Don’t worry if you don’t feel 100% with Git after the exercise. We will continue to use Git for the remainder of the program so you will get plenty of practice. After this lesson, we’ll include a concise step-by-step practical use guide for how to use Git in your workflow.

Git commands you will practice:

  • git init
  • git status
  • git add
  • git commit -m
  • git diff
  • git log

Important new terminology:

  • Git
  • repository
  • commit (a snapshot is often used to describe a commit)
  • untracked file
  • tracked file
  • unmodified, modified, staged changes in a file


Let’s learn a bit about how Git categorizes changes when they happen in your project. To start, we’ll set up Git in a brand new project. We’ll then make changes to our project to see how Git categorizes those changes. Then we’ll end with taking a snapshot of our project to preserve its current state in our project’s history.


This exercise assumes you have git installed on your computer following the directions in lesson Git an GitHub

Epicodus machines already have git installed.

Project Setup:

Let's Pair Program!
If working remotely in a pair group:
Using Git relies on using the terminal. We shouldn't share access to our terminal with other people for security reasons. So for this project, the person who sets up the project on their computer will be the driver for the entire exercise. Go through this exercise multiple times so everyone has an opportunity to be the driver.

Create a new directory on your desktop called hello-world. Navigate into that directory and create an HTML file called hello-world.html

Copy and paste this starter code to the hello-world.html file:

<h1> Hello World </h1>

<h2> A program to greet the planet. </h2>

<p>This page is an attempt to greet everyone on Earth using our various human languages.</p>

    <li> English: Hello, world! </li>
    <li> Spanish:  Hola, mundo! </li>
    <li> Japanese: Konnichiwa, sekai! </li>
    <li> French: Bonjour, monde! </li>
    <li> Kinyarwanda: Mwirwe, isi! </li>

Initialize Git

In the hello-world directory: type:

git init 

Hit Enter. The response should look something like:

$ git init

Initialized empty Git repository in /Users/staff/Desktop/hello-world/.git/

You only need to initialize git once per project.

A new directory has been made in your project called .git. The . before the directory name means it is a hidden file. You can view hidden files on your computer by using the ls -a terminal command.

The .git directory is a Git repository inside your project. It will be able to track changes made in your project. A repository in English is a place where things may be stored. Git uses the term repository to refer to where a project is stored.

We’re not going to explain how .git works. It’s not essential for us to know in order to use Git effectively . Just know that deleting the .git repository inside your project will delete your project’s history.

Git Status

The .git repository tracks changes in your project but you have to tell Git when to take a snapshot to preserve a record of those changes. It’s kinda like how a video game will have a save option but you have to use the save option in order for your progress to be recorded.

Let’s learn how Git categories change in your project as they happen.

Git puts all files in your project into two main categories: untracked or tracked status. Tracked files additionally have unmodified, modified, or staged status. A tracked file can have more than one additional status.

Git describes this as the lifecycle of the status of your file. For this lesson we are going to shorten that to just a status lifecycle. When describing the status lifecycle, we refer to the statuses: untracked, unmodified, modified, or staged. Here is a visual that represents the status lifecycle:

static image of lifecylce chart

Image from git-scm.com | 2.2 Git Basics - Recording Changes to the Repository.

In your terminal, navigate to the hello-world directory, type:

git status

Hit Enter. You should get a response something like this (our terminal theme may look different from yours):

static image of git response

The file hello-world.html is listed under “Untracked files” (circled in blue). This file is currently untracked so we’re here in the status lifecycle (the purple 1 in a circle):

static image fist status in lifecycle

The only place to go from status untracked is to staged. This means that even if you are to make changes to the hello-world.html file now and then run git status again, the file will remain as untracked. That’s because Git has no prior history of this file to compare to. The words “unmodified” and “modified” even imply that there needs to be something to compare against in order to have either of those statuses.

Git has nothing to compare against for hello-world.html because we just initialized git. We haven’t created any history yet.

Well, let’s create some history then. Let’s change the status of the hello-world.html file to staged.

In the hello-world directory, type:

git add hello-world.html

Hit Enter. You should get no response. Git usually does not give a response if the git command was successful. Don’t worry, if something goes wrong, Git is great at letting you know and often provides helpful suggestions.

So to see what happened, use git status again. You should see something like this:

changes to be commited terminal

“Changes to be committed” (circled in blue) means that these changes (now in green) are ready to be included the next time we take a snapshot of our project. That snapshot will be preserved in our project’s history as a commit. We can revisit any previous commits as we please.

We’ll make a commit in just a moment but first a little more information about status lifecycle:

The hello-world.html file has the status of staged because it has changes to be committed. In the the status lifecycle, we’re here (purple 2 in a circle):

second stage lifecycle

The tricky thing is that a tracked file can have more than one status from the options: unmodified, modified, staged.

To demonstrate, make any change to your hello-world.html file at this time and then use git status. You should see something like this:

two status file

The hello-world file now has the status of staged AND modified because some changes are staged under the “changes to be committed” section and the other changes are not.

In other words, we made additional changes after using the git add command. Git will not make the assumption that additional changes to a file should be included under “changes to be committed.”

This is good because we want to be the ones to make that decision. We don’t want Git to add changes that will be included in the next commit and preserved in our project history without us saying so.

Revisiting the status lifecycle chart, hello-world.html is now in two places (two purple 2 in a circle):

flowchart in two places

Now is a good time to try out a new git command: git diff hello-world.html This command is helpful to quickly see what changes happened in a modified file.

Moving on, if you want the new changes to be added to “changes to be committed” (and eventually included in our snapshot when we make a commit) you have to use git add hello-world.html again. Do that now and here is an example of what it should look like:

git add all files

Okay, let’s finally commit our changes so we can create a snapshot of our work and complete the file status lifecycle.

In the hello-world directory, type:

git commit -m “my first commit!”

Hit Enter. The response should look something like this:

response from git commit

The git commit command takes a snapshot of our project. The - m option stands for “message” and is followed by a commit message in quotes. A commit message is a brief note attached to the commit and it makes it easier for us to reference the commit at a later time.

You can check that a commit was created by using the git command git log in the terminal.

Now if you use git status you should get:

reponse no changes

The response doesn’t say this directly but Git is saying all files are now unmodified,meaning no new changes have happened since the last commit.

If we make changes to the hello-world.html file now, the status would change again to modified. The status lifecycle of a tracked file repeats between unmodified, modified, staged.

status lifesycle loop

Remember that a tracked file can have multiple statuses if some changes are staged under “changes to committed” and others are not.


You should have some understanding how Git categorizes changes in your file and the status lifecycle of files.

Don’t worry if this isn’t all making sense. You won’t be tested on Git status lifecycles of files. We offer this information now so you have some context for how Git works. When integrating Git into your workflow, use the command git status often, especially before making a commit.

In the next few lessons, we’ll go over a practical use step-by-step guide for exactly how to integrate Git into your workflow and what relevant git commands you should know.