Staging and committing

Why does Git have a staging step at all?

Picture the bakery site after a morning's work: a new heading colour in style.css and a new menu in index.html. They are two separate ideas. If the colour turns out to clash, you want to undo the colour without losing the menu.

The staging area lets you build each commit on purpose. You place exactly the changes you want with git add, check them, and then git commit saves that set and nothing else. Changes you did not stage stay in your working folder, untouched, ready for a later commit.

On a solo project with one change at a time, staging feels like an extra step. It earns its place on the day you have made three unrelated edits and want history to show them as three clear commits.

git status
git add style.css
git status

What does git add really copy?

git add style.css takes the file as it is on disk right now and puts that version in the staging area. It is a snapshot of the moment, not a promise to include whatever the file holds later.

If you edit style.css again after adding it, git status lists it twice: once under Changes to be committed (the version you staged) and once under Changes not staged (your newer edits). Committing then records only the staged version. Run git add style.css again to stage the newer one.

git add works on new files too. That is how an untracked file such as menu.html becomes tracked: add it, commit it, and from then on Git watches it for changes.

Which form of git add should I use?

There are a few common forms. They differ in what they pick up, and that is a bigger difference than how much typing they save.

• git add index.html style.css: stages the named files only. The most precise choice when you want separate commits.
• git add .: stages every change in the current folder and below, including new files and deletions. Fast, and the usual source of accidental commits.
• git add -A: like git add . but for the whole repository, whatever folder you are in.
• git add -u: stages changes to files Git already tracks, and skips new files. Handy when a stray draft sits in the folder.
• git add images/: stages everything inside one folder.

What happens when I commit?

git commit -m "Colour the bakery heading" takes everything in the staging area, wraps it with your message, your name and the time, and stores it as a new commit whose parent is the previous one. Your branch label moves forward to the new commit, which the Graph view shows as the main label sliding along.

Git prints a short report: the branch, the first seven characters of the new commit id, the message and how many files changed. After that, git status no longer mentions the files you committed.

If nothing is staged, Git refuses with nothing to commit and, when you have unstaged edits, reminds you to git add first. That message is the most common one beginners meet, and the cure is always to stage something.

git add style.css
git commit -m "Colour the bakery heading"
git log --oneline

Can I skip git add?

git commit -am "message" stages every change to tracked files and commits in one go. It is a real shortcut and fine when every edit belongs together.

It has two limits. It never picks up new files, so a fresh contact.html stays untracked and the commit silently leaves it out. And it gives you no chance to split unrelated work, which is the point of staging.

Real Git without -m opens a text editor for the message. The practice terminal has no editor, so always pass -m. On your own machine, if a strange screen appears after git commit, you are probably in the Vim editor: type :cq and press Enter to leave and cancel the commit, then try again with -m.

git add index.html
git commit -m "Add the menu"
echo "h2 { color: #a0522d; }" >> style.css
git commit -am "Colour the subheadings"
git log --oneline

How big should one commit be?

Aim for one commit per change you could describe in a short sentence. Adding the Saturday hours is one commit. Renaming every page and fixing a typo is two.

A useful test is undo. If you might want to undo this change without undoing anything else, it deserves its own commit. Commit sizes vary: a single changed character can be a perfect commit, and so can a new page with forty lines.

Commit working states where you can. A commit that leaves the site half-broken does no lasting harm. Still, history is far more useful when each dot on the Graph is a version you could publish.

How do I check what is staged before committing?

git status names the files. git status -s gives a compact view: two columns per file, where the left letter is the staging area and the right letter is the working folder. M means modified and staged, M means modified but not staged, A means a new file staged, and ?? means untracked.

To see the actual lines that will go in, run git diff --staged. Plain git diff shows only the changes you have not staged yet. The next lessons use both, and they are the best guard against committing something by accident.

Keep an eye on the Areas view while you practise. A staged file sits in the middle column; after the commit it moves into Last commit.

git add style.css
git status -s
git diff --staged

What should I look for in AI-suggested add and commit commands?

Generated instructions tend to stage everything at once. Look for these patterns.

• git add . followed straight by git commit: check git status in between, especially in a folder with notes, exports or .env files.
• git add *: the shell expands the star itself, so hidden files such as .gitignore are skipped and ignored files can trip errors. Prefer git add . or named files.
• git commit -am on a project with new files: the new files are left out.
• Placeholder messages such as "update" or "your message here": replace them with what you actually changed.

Field notes

• The staging area lets you split unrelated edits into separate commits.
• git add stages the file as it is right now; later edits need staging again.
• git commit -m saves everything staged, with your message, name and the time.
• Aim for one commit per change you can describe in a short sentence.

Easy to get wrong

Git commits only what is staged. A new file stays untracked until you add it, whatever the message says.

git add stages the file as it was at that moment. Later edits are left out of the commit.

The -a flag only stages files Git already tracks. Brand new files are skipped.

git add . takes everything that is not ignored. Name files, or set up .gitignore, when the folder holds things that must not be committed.

Questions people ask

How do I take a file out of the staging area?

Run git restore --staged <file>. The change stays in your working folder, it just will not be in the next commit. The lesson on undoing changes covers it in detail.

Can I stage part of a file?

On a real machine, git add -p walks through each changed block and asks which ones to stage. The practice terminal does not support it, so here you stage whole files.

Does committing upload my work?

No. A commit is stored only in your local .git folder. Sending commits to GitHub is a separate step called push.

What does the number after the branch name in the commit report mean?

It is the short commit id, the first seven characters of the full id. Use it with commands such as git show to refer to that commit.