Change a File Git Already Tracks

You have a repository with one commit in it. README.md is committed, and now the file needs to change. This is the ordinary rhythm of working with Git, and it is slightly different from making a first commit, because this time Git has seen the file before.

Change the file

Open it again with the terminal editor from the first lesson:

nano -w README.md

Add a third line below the two already there, so the file reads:

# Garden notes

The first repository will keep this file's history.
Beds are numbered from the gate.

Save with Ctrl-O, press Enter to confirm the name, then leave with Ctrl-X.

Modified is not the same as untracked

git status

In the last lesson, git status called README.md untracked. Git had never recorded that file, so it had nothing to hold the file up against. This time the same command calls it modified.

That one word is the point of this lesson. Git has a recorded version of README.md to compare against. A file becomes tracked when you add it to the staging area, even before its first commit. An untracked file has no entry there. For this edit, the staged version still matches the previous commit, so Git reports the difference between that saved version and your working file.

Notice also what Git did not do. Your third line is real and saved to disk, and Git recorded none of it. It is waiting to be asked, exactly as chapter 1 promised.

Stage the change, then record it

The rest is the loop you already ran once:

git add README.md
git status
git commit -m "Note how the beds are numbered"
git log

git add copies the file’s current contents into the staging area. The git status between the two commands is worth reading rather than skipping: it now describes the change as queued for the next commit instead of merely present on disk. git commit then records it, and git log shows two commits with the newest at the top.

The three places, named

Git keeps three versions in view, and you have now copied one file’s state forward through all of them:

1. The working tree: your files as they sit on disk. The third line arrived here when you saved it in nano.

2. The staging area: the snapshot you are preparing for the next commit. git add copied the current README.md into it.

3. The history: the snapshots Git has committed. git commit recorded the staged version, and that record is the one that lasts.

These are not boxes that a change physically moves between. The working file remains on disk after git add, and a committed version remains in history while you edit the next one. The versions can differ at more than one boundary at once.

git status tells you which of those comparisons currently differ: working tree from staging, or staging from the newest commit. When anything in the rest of this course leaves you unsure, run it before you run any other Git command.

That is a complete repository of your own: two commits, a readable history, and an identity attached to both. Next you will open a repository you did not write, with eleven commits already in it, and learn to read what other people did.