Your first commit

The loop

git status is the most-run command in git, and it is worth reading properly: it tells you the branch, what is staged, what is changed but not staged, and what git has never seen.

four commands, in a circle, all day

git status                 # where am I?
git add price-list.md      # this goes in the next commit
git commit -m "Add the autumn price list"
git log --oneline          # and there it is

What status is telling you

three groups, three different fixes

On branch main

Changes to be committed:        # in the index — the next commit will have these
        new file:   price-list.md

Changes not staged for commit:  # changed since you staged it
        modified:   notes.md

Untracked files:                # git has never seen this one
        draft.md

git status -s

The short form fits on one screen: A staged, M modified, ?? untracked, AM both. Once the long output stops surprising you, the short one is faster.

add takes paths, and the paths matter

git add . is the habit that produces commits containing a debug log, a stray screenshot and half of another feature. Staging on purpose is what makes the next lesson's history readable.

be specific when it matters

git add price-list.md          # one file
git add src/                   # a directory
git add .                      # everything below here, including new files
git add -p                     # interactively, hunk by hunk — the good one

The message

Write it in the imperative — "Add", "Fix", "Move" — because that is how git itself writes ("Merge branch…", "Revert…"), and because it finishes the sentence this commit will…. Under fifty characters for the subject; if you need more, git commit with no -m opens an editor and you can write a body after a blank line.

a subject line someone can scan

git commit -m "Add the autumn price list"
git commit -m "Fix the total when a line is discounted"

# not this
git commit -m "update"
git commit -m "fixes"
git commit -m "asdf"

Two shortcuts worth knowing

and one to be careful with

git commit -am "Fix the discount"   # stage every TRACKED file, then commit
                                    # (new files are not tracked — this skips them)

git commit --amend -m "Better message"   # replace the last commit
                                         # it gets a NEW id: never do this to a
                                         # commit other people already have

Nothing is lost until it was never added

A committed change is effectively permanent — even "deleted" branches and amended commits are recoverable for weeks through the reflog. What git cannot help with is work you never staged and never committed. That is the real argument for committing often: small, boring, frequent commits, squashed later if you like.