From working tree to history: the commit lifecycle

A snapshot of a snapshot

The last course introduced three states a file moves through, and let you use git add and git commit just enough to prove a repository worked. This course is the deep dive. It covers every option, every safety net, and the habits that make a commit history readable for a teammate.

Start from the exact model you already know:

Working Tree          Staging Area           Repository (history)
(files on disk)  ──▶  (about to commit)  ──▶  (permanent snapshots)
  git add                git commit

The detail worth internalizing today: a commit is a snapshot of the staging area, not of your working tree. If you edit a file after staging it, that edit is not automatically included. This one fact explains most "but I definitely saved that change!" surprises.

Prove it

cd ~/code/git-playground
echo "line one" > notes.txt
git add notes.txt
echo "line two" >> notes.txt
git commit -m "Add notes"
git show --stat HEAD

 notes.txt | 1 +
 1 file changed, 1 insertion(+)

Only "line one" made it into the commit. "line two" was written to the working tree after git add ran, so the staging area never saw it. It is still there, unstaged, waiting for the next git add. Confirm:

git status

Changes not staged for commit:
  modified:   notes.txt

Why a separate staging step exists at all

It would be simpler if git commit just grabbed everything on disk. Real work is rarely one clean change. You fix a bug, notice an unrelated typo, and add a debug puts you meant to delete. Staging lets you build a commit that is one logical change, even when your working tree is messier than that.

This course follows that idea. Lesson 2 covers git add in detail, including staging part of a file. Lesson 3 covers the message that explains the change. Lessons 4–6 cover fixing mistakes at every stage, and Lesson 7 puts it all together on a real feature.

Three commands, refreshed

A quick reminder of the three you already have, since every lesson from here uses them constantly:

That last one is the command to run before every single commit, without exception, for the rest of your career.

Key takeaways

• A commit captures the staging area, not the working tree: edits made after git add need to be staged again.
• The staging area exists to let you build one clean, logical commit out of a working tree that has several unrelated changes mixed together.
• git diff --staged shows what the next commit will contain: run it before every commit.
• This course covers add, message-writing, and every safe way to undo a mistake at each stage of the pipeline.