Modify a tracked file and commit

So far you've added new files to Git. But most of the time you're not adding files, you're editing existing ones. This lesson covers the everyday workflow: change a tracked file, commit the change.

Tracked vs untracked

Git puts every file in your repo into one of two buckets:

• Untracked: Git knows the file exists but isn't watching it. New files start out untracked until you git add them.
• Tracked: Git is watching the file. It notices when you edit it, delete it, or rename it.

Once a file is tracked, Git notices every change you make to it without you having to tell Git anything. Try it: edit a tracked file in your editor, save, then run git status. Git will report the file as modified.

The modified state

When you change a tracked file, Git puts it in a new state: modified, not staged. That means: "I noticed you changed this, but you haven't told me you want to include the change in the next commit yet."

git status shows this clearly:

Changes not staged for commit:
        modified:   README.md

To see what changed, run:

git diff

Git shows you the unstaged changes line by line, with additions prefixed + and deletions prefixed -. This is the fastest way to review your own work before committing.

Same two step pattern

Modifying and committing uses exactly the same commands as adding and committing:

git add README.md
git commit -m "Add status heading"

git add stages the modified version. git commit records the snapshot. If you forget git add and jump straight to git commit, Git commits the previous (unchanged) version of the file because the modifications are still sitting in the working directory, unstaged. This is a very common surprise. git status before every commit will save you from it.

Appending vs overwriting on the shell

When you're editing files from the terminal, watch the redirect operators:

• echo "line" > file.md overwrites the file. Old content gone.
• echo "line" >> file.md appends to the file. Old content preserved.

One character of difference, big consequence. If you meant to add a line to the bottom of your README and used > instead of >>, Git will faithfully commit your accidentally erased file. That's not a Git bug, that's a shell fact of life. Read the operator you type.

The repository already has one commit (Add README) and README.md is tracked. Append the line ## Status to the end of README.md, then stage and commit the change with the message Add status heading. After this, git log --oneline should show two commits and the working tree should be clean.