Your First Commit

Two commands, and Sandpiper has a history. This page runs the loop twice, because the second time is when it stops feeling like a ceremony and starts feeling like typing.

Stage it

git add puts a file's current contents into the staging area — the box from the last topic.

git add index.html
git status

Git now lists index.html under changes to be committed. That phrase is Git's way of saying "in the box". Nothing has been recorded yet; you have only chosen what will be.

Commit it

git commit -m "Add the club home page"

Git answers with a line like [main (root-commit) a3f9c21] Add the club home page, followed by how many files changed. Read it: the branch you are on, a short identifier for the commit, and your message. Sandpiper now has exactly one commit, and its first version is recorded permanently.

The -m is the message option from Chapter 1. Leave it out and Git opens a text editor and waits for you to type one, which is where a great many beginners meet Vim unexpectedly and cannot get out. Use -m.

Do it again

One commit is a demonstration. Two is a history. Create style.css in the project — even a couple of lines is enough — and run the loop again:

git add style.css
git commit -m "Add basic styling for the home page"

That is the rhythm. Change something, put the finished part in the box, record it with a sentence saying why. Everything else in this book is a variation on those two commands or a way of fixing them.

What git add . really means

You will see git add . everywhere. The dot means "this folder and everything below it", so the command stages every change Git can see.

It is convenient, and it is the reason people accidentally commit passwords, private notes and four hundred megabytes of junk. The command does exactly what it says; the problem is that most people run it without knowing what "everything" currently contains.

The habit that makes it safe is thirty seconds long: run git status first and read the list. Chapter 5 is the systematic fix, where you teach Git to stop offering you files that should never be committed at all.

Committing part of your work

Here is staging paying for itself the first time. Suppose you have edited three files but only two of them are finished:

git add index.html style.css
git commit -m "Add the sightings section to the home page"
git status

The commit contains two files. The third is still sitting in your working directory, exactly as you left it, ready to be finished and committed separately. Nothing was undone and nothing was rushed.

One thing that surprises everyone

Stage a file, then edit it again before committing. Run git status and the same file appears twice — once under changes to be committed, once under changes not staged.

Nothing has gone wrong. git add stages the file's contents at the moment you run it, not the file as a permanent subscription. The earlier version is in the box; the newer edit is still on the desk. Run git add again to update the box. This is behind most "I committed it but my change is missing" confusion in week two.