The core loop — add, commit, status
The core git loop is edit then stage then commit. git status shows tracked vs untracked files; git add picks exactly what goes into the next commit; git commit -m records it. Learn the staging area, git add . vs explicit paths, and the -am shortcut and its caveat.
You changed five files but only two of them belong in this commit — the other three are half-finished experiments. In most “save” systems you would have no choice: everything saves together. Git is different. It puts a deliberate gap between changing a file and recording it, and that gap is the single most important habit in day-to-day git.
By the end of this lesson you will be able to run the everyday loop — edit, git add, git commit — read git status confidently, and stage exactly the changes you intend, not everything at once.
After this lesson you can describe the edit → stage → commit loop, explain the difference between tracked and untracked files and the role of the staging area, and use git status, git add, and git commit -m to record a chosen subset of your changes.
Every change you record passes through three places: the working tree, the staging area, and the repository. The working tree is your files as they sit on disk right now. The repository is the committed history in .git. Between them sits the staging area (also called the index) — a holding zone where you assemble the exact contents of your next commit. git add copies a change from the working tree into the staging area; git commit records whatever is staged as a new commit. Nothing is recorded until you commit, and only what you staged gets recorded.
git status is the command you run constantly to see where each file stands. It groups your files into three buckets:
git status- Untracked — files git has never been told about. Brand-new files start here.
- Changes not staged for commit — tracked files you have edited but not yet
add-ed. - Changes to be committed — what is currently in the staging area, ready to go.
A tracked file is one git already knows about from a previous commit or git add; an untracked file exists on disk but is not yet under version control. Run git status before every commit so you never record something by accident.
git add stages changes — and you control exactly how much. You can stage one file, several files, or everything:
git add src/login.js # stage one specific file
git add src/login.js README.md # stage several explicit paths
git add . # stage every change under the current directorygit add . is convenient but blunt: it stages all changes — including new files and half-done edits — under your current path. On a focused commit, naming explicit paths keeps junk out of history. Staging a subset is the whole point of the index: you decide which of your five edited files become this commit.
git commit records the staged snapshot, and the message explains why. The -m flag supplies the message inline:
git commit -m "Add login form validation"This commits only what is staged — the unstaged experiments stay in your working tree, untouched, for a later commit. After committing, git status shows a clean tree for the parts you recorded. The loop then repeats: edit, git add, git commit.
▸Edge cases
There is a shortcut, git commit -am "msg", that stages and commits in one step — but read the caveat carefully. The -a flag auto-stages only files git is already tracking. Brand-new (untracked) files are skipped entirely. So git commit -am after creating newfile.js will silently leave that file out of the commit. It is handy for quick edits to existing files, but for anything involving new files, stage explicitly with git add first and check git status.
Recording two of five changes.
You edited login.js and signup.js (a real bug fix) plus notes.txt, and created two scratch files tmp1.js and tmp2.js you are not ready to keep. Running git status shows login.js, signup.js, notes.txt as changes not staged, and tmp1.js, tmp2.js as untracked.
You want only the bug fix in this commit:
git add login.js signup.js
git status # confirms only those two are "to be committed"
git commit -m "Fix null check in login and signup flows"The commit contains exactly the two files. notes.txt and both scratch files are untouched in the working tree, waiting for separate, cleaner commits later. Had you typed git add ., all five would have been staged — the scratch files would have entered history, and you would have spent the next minutes untangling it.
▸Why this works
Why have a staging area at all — why not just commit whatever changed? Because real work is messy: in one editing session you fix a bug, rename a variable, and leave a TODO. The index lets you slice that mess into clean, single-purpose commits — stage the bug fix, commit it, stage the rename, commit that. A reviewer reading your history later sees three intentional changes instead of one tangled blob. git add -p takes this further, letting you stage individual hunks within a single file interactively; you will use it once your commits get crowded.
You created a new file auth.js, then ran git commit -am 'Add auth'. What happens?
The everyday git loop is edit → git add → git commit, with git status read constantly in between. The staging area (index) is a holding zone where you assemble the next commit, which is why git separates changing a file from recording it. Tracked files git already knows; untracked files are new and must be add-ed before they can be committed. git add <paths> stages a chosen subset; git add . stages everything under the current path; git commit -m records only what is staged. The -am shortcut is convenient but silently skips untracked files. Next you will learn to read exactly what you changed — git diff and git log — before you commit it.
Practice
Start at the top. Tasks go easiest → hardest: recall a fact, apply it to a case, then a senior-level stretch. Open one, attempt it, then reveal.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.