Committing Changes

A commit is the snapshot that actually lands in history. Asha will read her commits months from now, so each one should be a single, clear step: one idea, one message.

The rule

One commit, one idea, with a message that finishes "This commit will…".

After staging, record the snapshot:

Each commit stores:

• a snapshot of every tracked file as it was staged,
• the author (from user.name and user.email) and the time,
• the message,
• a link to its parent commit, the one before it. That link is what turns separate snapshots into a history.

Git gives every commit a unique ID, a long hash such as 4f9c2e1…. The first seven or so characters are usually enough to name it.

Good messages are short, specific and written as a command: "Add chai recipe", "Fix oven temperature in bread", "Remove duplicate salt line". A handy test: the message should complete the sentence "If applied, this commit will…". Messages like "stuff", "fix" or "changes" tell future readers nothing.

Keep commits focused. If you fixed a typo and also rewrote a recipe, stage and commit them separately. A focused commit is easy to understand, easy to review and easy to undo on its own.

Two handy variations:

-a only includes files Git already tracks. A brand-new, untracked file still needs git add first.

If you run git commit with nothing staged, Git reports that there is nothing to commit and makes no snapshot.

The shortcut

Before committing, read your staged changes with git diff --staged and say the message out loud. If you need the word "and", it is probably two commits.

The trap is the giant end-of-day commit named "update". It works today and becomes useless the first time you need to find or undo one specific change.

Drills

Answer fast — trust the rule.

Remember

• One commit, one idea, with a message that finishes "This commit will…".
• Read git diff --staged first; if the message needs "and", split it.
• -a stages modified tracked files only; new files still need git add.