Watch Git Save Me From a Failing Grade!

The del command can be a scary thing. You use it in the Windows Command Prompt to delete files. They disappear immediately; you can’t even retrieve them from the Recycle Bin. (The equivalent on Mac or Linux systems would be the rm command.)

Let me show you. First I’ll run the dir command to view the contents of the current directory:

C:\work>dir
09/10/2018  04:07 PM    <DIR>          .
09/10/2018  04:07 PM    <DIR>          ..
09/10/2018  04:07 PM            12,359 term_paper.txt
               1 File(s)         12,359 bytes

And now I’ll run the del command to delete that term_paper.txt file.

C:\work\>del term_paper.txt

If I run dir again, we can see the file is gone.

C:\work>dir
09/10/2018  04:09 PM    <DIR>          .
09/10/2018  04:09 PM    <DIR>          ..
               0 File(s)              0 bytes

…Oh, crap. I needed to turn that in tomorrow.

Okay, no worries. This is why I keep my files in the Git version control system. I’ll just run the git status command to check the status of my files…

C:\work>git status
On branch master
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        deleted:    term_paper.txt

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

Git knows that I had a term_paper.txt file, but that it was deleted. It also says that I can run the command git checkout -- <file>. Let’s try that with the term_paper.txt file.

C:\work>git checkout -- term_paper.txt

Now let’s try running dir to list the directory contents one more time…

C:\work>dir
09/10/2018  04:07 PM    <DIR>          .
09/10/2018  04:07 PM    <DIR>          ..
09/10/2018  04:07 PM            12,359 term_paper.txt
               1 File(s)         12,359 bytes

Whew! Crisis averted. The term_paper.txt file is back!

How Do I Use Git?

So, how was Git able to get the deleted file back for me?

Git is a version control system. It helps you control the different versions of the files in your project. It keeps track of all the changes to your files over time. If you ask it to, it can reset any file’s contents to match a previous version.

The collection of all the old versions of your project’s files is known as a Git repository. It’s basically just a folder in which you can edit your files, then run Git commands to store your changes. You can have multiple Git repositories on your computer, one for each project you’re working on.

Each time you complete a change to some or all of your project’s files, you can take a snapshot of their current contents. This snapshot represents a point in your project’s history that you might want to travel back to sometime in the future. These snapshots are known as commits. Just as you might take a phone number and “commit it to memory” so you can remember it later, you can commit a version of your project’s files to your Git repository so you can get that version back later.

All Git had to do was give me back a version of the term_paper.txt file that I’d recorded in a previous commit.

Let me show you how I set up the Git repository where the files were stored.

I changed into the project directory with the cd command, and then initialized the new repository with the git init command.

C:\Users\jay>cd \work

C:\work>git init
Initialized empty Git repository in C:/work/.git/

Like all Git commands, git init starts with the name of the git executable, followed by a space. Then, I typed the name of the subcommand I wanted to run, like add or commit or, in this case, init. Git initialized a repository in the current directory, by creating a new subdirectory named .git within it.

But at that point, my term_paper.txt file hadn’t been added to the repository yet. In fact, Git had no idea it existed!

There are three states every file goes through in a Git repository. When you make changes to a file, it’s “modified”. You don’t necessarily want to include all of your modified files in your next commit, so you need to specify which ones you will include. You do this by adding files to the index, more commonly known as the “staging area” or “cache”. The staging area is where you place the files you’re going to commit. Files you’ve added to the index are referred to as “staged” files. When you’ve staged all the files you want, you make a commit, and that’s when the files are actually added to your Git repository.

Then, when you next make a change to any of those files, they’re treated as “modified” again. You can stage and commit the files again to save a new version of them. And the cycle repeats.

So there I was, with a new Git repository, but nothing actually in it. I ran the git status command to find out the status of my files.

C:\work>git status
On branch master

No commits yet

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

        term_paper.txt

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

The git status command is the go-to command to find out the current status, or “what’s going on with Git”. It’s used a lot.

I saw my term_paper.txt file in the list of “untracked files”. These are files that Git isn’t “tracking” yet – it’s not keeping track of changes to them so we’re not saving new versions of them. I also saw a couple helpful messages encouraging me to run the git add command. So I did…

C:\work>git add term_paper.txt

Then I ran git status again…

C:\work>git status
On branch master

No commits yet

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

        new file:   term_paper.txt

The term_paper.txt file had moved to a new “Changes to be committed” section, which lists files in the staging area. The file had transitioned from “modified” to “staged”. Next, I needed to commit my changes to the repository. I ran the git commit command:

C:\work>git commit

This launched nano, a simple text editor, so that I could write a commit message.

In Git, you need to provide a message to go with every commit, a brief note explaining what the commit does. These messages are one of many features that make Git a great tool for collaborating with other developers. Messages are permanently attached to a commit in the repo history. If one of your collaborators sees a commit in the future and doesn’t understand it, the commit message will help them figure it out. It might also help you figure out what your own commit does, if it’s been 6 months since you made it.

So I wrote “Add term paper” as my commit message, saved the file, and exited the editor. Git took that as its signal to complete the commit, and saved term_paper.txt to the repo, along with the commit message. Git printed some output confirming the commit:

C:\work>git commit
[master (root-commit) f67d974] Add term paper
 1 file changed, 1 insertion(+)
 create mode 100644 term_paper.txt

As I continued working on my paper, I would occasionally run git add term_paper.txt to stage the file, and then git commit to commit a new version of it. I knew that if I made a change I didn’t like, I could reset to a previous version of the paper.

And the rest, you know. I made the ultimate change that I didn’t like: accidentally deleting the file. But because I’d committed it to the repo, Git was able to bring the file right back!

But Wait, There’s More!

Pretty cool, right? But restoring deleted files is only a tiny portion of what Git can do. Far more importantly, Git is a powerful way to share work across a team. With just a couple commands, you can clone an entire repository, including all its history, to another computer, where other people can make their own changes. And Git includes commands that let you easily bring changes from other people’s repositories back into your repository. These features also let you work with code hosting services, like GitHub.

If you’d like to learn more about Git, you should check out Treehouse’s Introduction to Git course. Once you master Git, you’ll never worry about losing your work again!