Committing, Staging and History

The three-stage mental model

Git has three areas worth understanding from day one: your working directory (the actual files you are editing), the staging area (changes you have marked as ready to be committed), and the repository (the permanent, committed history). Understanding this three-step flow is the single biggest thing that makes Git commands click instead of feeling arbitrary.

git status                  # see what has changedngit add index.html          # stage one specific filengit add .                   # stage everything that changedngit commit -m "Add homepage"

Why staging exists at all

Staging lets you build a commit out of only some of your current changes — useful when you have been working on two unrelated things at once and want them recorded as two separate, clean commits rather than one tangled one. Many beginners just git add . everything every time, which is a perfectly reasonable default until you specifically need this finer control.

Writing good commit messages

git commit -m "Fix broken link in footer"        # good: specific, describes what changedngit commit -m "updates"                          # not helpful six months from now

A commit message is a note to your future self and to every teammate who will ever read this project’s history — “Fix broken link in footer” tells you exactly what to expect; “updates” tells you nothing when you are trying to find which commit introduced a bug months later.

Viewing history

git log                     # full historyngit log --oneline           # one line per commit, easier to scanngit show <commit-hash>      # see exactly what one commit changed

Every commit gets a unique hash (a long string like a3f9c2e) that identifies it forever — you only ever need to type the first several characters for Git to recognize which commit you mean.