The Daily Loop

Every working day in git is one loop: edit files in the working directory, stage exactly what belongs together, commit it with a message that names it. Everything else in this chapter is that loop, slowed down enough to see the gears.

The repository here is real - Maria's ledger from this chapter's own repo - and every terminal block below is its actual output.

$ git add ledger.md
# ledger.md gains a line - the desk moves on
$ git status   # the long report tells both truths
... 
	new file:   ledger.md
... 
	modified:   ledger.md
... (untracked section below)

git add copies a file into the staging area as it is at that second. Maria stages ledger.md, then adds a coffee line to the desk copy. The staged copy does not follow. This is not a quirk - it is the design: the staging area holds the exact next commit you are composing, immune to whatever the desk does next.

$ git status
On branch main
No commits yet
Changes to be committed:
  ... (hint trimmed)
	new file:   ledger.md
Changes not staged for commit:
  ... (hints trimmed)
	modified:   ledger.md
Untracked files:
  ... (hint trimmed)
	build/
	notes.md
	secrets.env

Before anything else, the habit: git status. Its three sections are three comparisons - staged vs last commit, working directory vs staged, and paths the staging area does not yet hold. The same file can honestly appear in two sections at once, because two different comparisons can both be true.

$ git commit  -m "file the opening ledger"
[main (root-commit) dd83501] file the opening ledger
 1 file changed, 1 insertion(+)
 create mode 100644 ledger.md

git commit seals what is staged into ONE commit. The id - dd83501 here - exists only from this moment, derived from the contents. Note the honesty of the seal: the coffee line never entered the staging area, so it is not in this commit. The desk still holds it, and status still says so.

When to commit: one self-contained change, with a message that names it. "stuff" helps nobody - including you, next month.

Staging has range controls. git add -p walks one file hunk by hunk, asking y or n - in this repo, the soup price went in and the risotto edit stayed on the desk, so each fix can become its own commit. git add -A spans the whole repository, deletions included; git add . reaches only the current folder down - standing in a subfolder, every change elsewhere (edits, new files, deletions) is quietly missed.

"Clean" means status has nothing to report: staged, committed, and desk agree - ignored paths are deliberately left out of the report, and the staging area is NOT empty. After a commit, staged and committed match by construction; the report is clean only when the desk agrees too. Maria's coffee line keeps the report honest until she stages and seals a second commit.

$ git commit --amend -m "standing keep-out order"
[main c6b9e1d] standing keep-out order
 ... (detail lines trimmed)
$ git cat-file -t e731b31
commit

The loop's one rewind: git commit --amend re-seals the last commit as a replacement - e731b31 became c6b9e1d in this repo, same purpose, new id. The old commit is not destroyed - the branch walks away, and the reflog still lists it (that story belongs to the Undo Without Fear chapter); and the law that follows you for the rest of the course: never amend a commit you have already shared.

a)  M ledger.md
b) ?? notes.md
c) MM report.md

Exercise - from this chapter's own repositories, three moments are seated here. For each: say which places disagree, then name the command(s) that move the desk's truth into a commit. The real terminal output above holds the answers.