Your first real commits

Time to actually use it. This lesson is deliberately hands-on — open a terminal in a throwaway folder and run each command as you read.

Starting a repository

git init

Turns the current folder into a Git repository. Run it once, at the root of your project.

The core loop

git status          # what's changed, what's staged, what isn't
git add <file>       # stage a file (or "git add ." for everything)
git commit -m "message"   # seal the staged changes into a snapshot
git log              # see the history you've built

Run git status constantly — more than feels necessary at first. It's the single most useful command in Git because it tells you exactly what state you're in before you do anything else. Beginners who skip it are the ones who get surprised by their own repository.

Writing a commit message that isn't "fix stuff"

A commit message has one job: let someone (often future-you, six months from now) understand why this change happened without having to read the diff. A useful convention:

• First line: a short summary in the imperative mood — "Add login validation," not "Added" or "Adding." Imagine it completing the sentence "If applied, this commit will ___."
• Leave a blank line, then explain why if it's not obvious — what problem this solves, not just what changed (the diff already shows what changed).

git log --oneline is worth running often too — it compresses your history into one line per commit, which makes a messy commit message habit very visible, very fast.

The checkpoint for this lesson

Initialize a real Git repository somewhere (even a throwaway folder), and make at least three commits that build on each other, each with a message that would make sense to someone who wasn't there when you wrote it.