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:

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.

A Git repository allows you to save multiple versions of each of your files.

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.

Git files cycle through three states: “modified”, “staged”, and “committed”.

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…

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.

The “git commit” command launches a text editor so you can 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:

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!

I'm an instructor for Treehouse. I'm also the author of Head First Ruby and Head First Go, both published by O'Reilly Media. I've spoken at RubyConf, OSCON and many other conferences. (I have a knack for explaining things, or so I hear.)

If you dream of becoming a software developer, or you want to level up your programming skills, check out our Techdegrees:

Each is designed by our faculty of tech professionals to guide even a coding beginner to becoming a job-ready software developer armed with a professional portfolio of real-world projects. Try one out today with our free seven-day trial, and see if software development is for you.