Review and Commit One Change

The ignore rules keep local machinery out of the history. They do not decide when useful project work is ready. That decision comes from a short review before each commit: see what changed, stage the one coherent change you mean to record, inspect the staged snapshot, and give it a subject another reader can use.

The project currently has its weekend forecast in forecast.py. Your next piece of work is deliberately small: add a separate Monday notice in monday.txt, and nothing else.

Review the working-tree change

Create monday.txt with the same terminal editor used earlier:

nano -w monday.txt

Enter this one line:

Monday: bright spells

Save with Ctrl-O, press Enter, then leave with Ctrl-X.

You already know git status as the overview of outstanding paths and git diff as the exact unstaged changes to paths Git already tracks. Use both before staging. Here, status names monday.txt, but git diff prints nothing because the new file is still untracked and is not yet part of Git’s working-tree comparison:

git status
git diff

That empty diff does not mean the file is empty or ready to commit; git status is what tells you the new path still needs a decision. If another path appears, settle it before continuing rather than sweeping unrelated work into this commit.

Review the snapshot Git will commit

git add monday.txt stages the current version of that one file. Once a change is staged, plain git diff compares the working tree with the index and may print nothing. To inspect the prepared snapshot, use git diff --staged. The option --staged tells git diff to compare the index with the newest commit instead.

Stage the file, then inspect that prepared snapshot and its status:

git add monday.txt
git diff --staged
git status

The staged diff should show the new file and its Monday line. This is the last cheap moment to catch an accidental extra line, an unrelated edit, or a private value before it becomes history.

Give one change one useful subject

The first line of a commit message is its subject. A useful subject tells a reader what changed and where well enough to distinguish this commit from its neighbors. Add the Monday forecast does that. Subjects such as update, changes, or wip make the reader open every snapshot just to learn what it was for.

A commit’s scope is the coherent piece of work it contains. Small does not mean an arbitrary limit of one file or five lines. It means the commit has one reason to exist. The Monday forecast is one reason; mixing it with new ignore rules or a rewritten README would create several.

git commit -m records the staged snapshot and uses the quoted text as its subject. Commit the reviewed change, then use plain git log to read the two learner subjects and git status to confirm there is nothing unfinished:

git commit -m "Add the Monday forecast"
git log
git status

The newest two subjects should describe two separate decisions: add Monday, and keep local project files out of Git. The final status should be clean even though the ignored dummy and generated files remain on disk.

That is the complete habit: keep local machinery outside the history, inspect what the index is about to record, and leave each coherent snapshot with a subject that helps the next reader.