You spent an evening on the portfolio. You added a navigation bar to index.html, created styles.css, and fixed a typo in your name along the way. That’s three unrelated changes. If you commit them together as “updates”, future you can’t undo the nav without also undoing the typo fix. Git gives you a place to sort changes before they become history.
Every change in a Git project lives in one of three places:
\ngit add copies a file’s current content into it..git. git commit turns the index into a new commit.After a commit, the index isn’t emptied. It still holds the full snapshot you just committed, so it matches the last commit until you stage something new. That’s why “staged changes” means the difference between the index and the last commit.
\nHere’s the evening’s work, checked with git status:
On branch main\nChanges not staged for commit:\n (use "git add <file>..." to update what will be committed)\n (use "git restore <file>..." to discard changes in working directory)\n\tmodified: index.html\n\nUntracked files:\n (use "git add <file>..." to include in what will be committed)\n\tstyles.css\n\nno changes added to commit (use "git add" and/or "git commit -a")git status tells you which files differ. To see the lines, use git diff, and remember there are two comparisons:
git diff # working tree vs index: what you haven't staged yet\ngit diff --staged # index vs last commit: what the next commit will contain--cached is an older synonym for --staged; you’ll see both in tutorials. Get into the habit of running git diff --staged right before every commit. It’s the last moment to notice a stray console.log or a file that doesn’t belong.
The typo fix and the nav bar are both in index.html. git add index.html would stage both. Stage just the typo instead:
git add -p index.htmlGit shows each changed block, called a hunk, and asks Stage this hunk [y,n,q,a,d,s,e,?]? (newer versions list a few more letters; ? explains them all). Answer y for the typo hunk and n for the nav hunk (s splits a hunk that’s too big). Then:
git diff --staged # only the typo fix\ngit commit -m \"Fix spelling of name in header\"\ngit add index.html styles.css\ngit commit -m \"Add navigation bar with base styles\"Two commits, each with one purpose. Later, if the nav bar needs to go, you can undo that commit alone.
\nA good commit does one thing you could describe in a short sentence without the word “and”. “Fix spelling of name in header” passes. “Add nav, fix typo, tweak colours” fails, and the failure shows up later: when the colours turn out wrong, undoing that commit also removes the nav and brings back the typo.
\nThere’s no line limit. A commit that renames a CSS class across twelve files is still one idea, and splitting it would leave the site broken in between. Aim for commits where the project still works before and after, each one a step you could explain to a reviewer in one breath. You’ll appreciate this in section 4, when undoing a single commit becomes a one-line command instead of an afternoon of surgery.
\n\ngit status -s packs the same information into two columns: the left is the index versus the last commit, the right is the working tree versus the index.
M README.md\n M index.html\nMM styles.css\n?? projects.htmlREADME.md is staged; index.html has unstaged changes; styles.css has some of each; projects.html is untracked.
To take a file out of the index without losing your edits, use git restore --staged styles.css. To throw away unstaged edits and go back to the index version, use git restore styles.css. The second one is the only command in this lesson that destroys work: changes that were never staged or committed can’t be recovered.
You can now record exactly the history you mean to. Next you’ll read that history back, and see why Git calls it a graph rather than a list.
\n","toc":[{"id":"sec-1","text":"Three places your work can be","level":2},{"id":"sec-2","text":"Seeing the difference: status and two diffs","level":2},{"id":"sec-3","text":"Splitting one file into two commits","level":2},{"id":"sec-4","text":"How big should a commit be?","level":2},{"id":"sec-5","text":"Short status, and backing out","level":2}],"takeaways":["The working tree is your files, the index (staging area) is the next commit being assembled, and the repository is the commits already recorded.","git diff compares the working tree to the index; git diff --staged compares the index to the last commit.","git add -p stages part of a file, so one messy editing session can become several focused commits.","git restore --staged <file> unstages and keeps your edits; git restore <file> throws your unstaged edits away.","git commit -a stages modified tracked files only; brand-new files still need git add."],"further":[{"title":"Recording Changes to the Repository (Pro Git)","url":"https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository"},{"title":"git restore reference","url":"https://git-scm.com/docs/git-restore"},{"title":"git add reference","url":"https://git-scm.com/docs/git-add"}],"quiz":[{"q":"You staged index.html, then edited it again. git diff shows only the second edit. Why?
git diff --staged would show it."},{"text":"git diff only shows the most recent save of each file.","why":"Git doesn’t track saves. It compares two whole states, and which two depends on the command."},{"text":"git diff compares the working tree to the index, and the first edit is already in the index.","why":"Correct. With the first edit staged, the only difference left between the file on disk and the index is the second edit."},{"text":"The second add is required before git diff shows anything.","why":"git diff shows unstaged changes, which is exactly what the second edit is. Staging it would make git diff show nothing."}],"answer":2},{"q":"You ran git add styles.css but want it in the next commit after all, not this one. Which command keeps your edits and only unstages the file?
git restore --staged styles.css","why":"Correct. It copies the last committed version into the index, so the file is unstaged while your edits stay in the working tree."},{"text":"git restore styles.css","why":"Without --staged this targets the working tree and replaces your file with the index version. Your edits would be gone."},{"text":"git rm styles.css","why":"This stages the file’s deletion and removes it from disk. That’s the opposite of what you want."},{"text":"git commit --skip styles.css","why":"There’s no --skip option on git commit. Unstaging happens in the index before you commit."}],"answer":0},{"q":"You created projects.html and edited index.html, then ran git commit -am "Add projects page". What did the commit contain?
-a means all files in the folder.","why":"-a means all modified tracked files. A file Git has never tracked isn’t included."},{"text":"Nothing, because -a can’t be combined with -m.","why":"-am is a common and valid combination: stage tracked changes, then commit with this message."},{"text":"Only projects.html, because it’s the newer file.","why":"The age of a file doesn’t matter to Git. What matters is whether it’s tracked."},{"text":"Only the index.html changes; projects.html is still untracked.","why":"Correct. -a skips untracked files, which is why the commit message now describes a page that isn’t in the commit."}],"answer":3},{"q":"In git status -s, what does the line MM index.html tell you?
UU (unmerged) in short status, not MM."}],"answer":1}],"exercise":{"kind":"fill","language":"bash","template":"git status\ngit add {{0}} index.html # stage only the typo-fix hunk\ngit diff {{1}} # check what the next commit contains\ngit commit -m \"Fix spelling of name in header\"\n\ngit add index.html styles.css\ngit restore {{2}} styles.css # oops: unstage it, keep the edits\ngit commit -m \"Add navigation bar\"","blanks":[{"answers":["-p","--patch"]},{"answers":["--staged","--cached"]},{"answers":["--staged","-S"]}],"title":"Stage on purpose","prompt":"Complete the session. You stage only part of index.html (the typo fix), check exactly what will be committed, commit it, then stage the nav work but take styles.css back out of the index without losing your edits.
git diff shows unstaged changes. The flag you need compares the index with the last commit.","The same git restore command can either discard edits or unstage. Only one of those is safe here."],"explanation":"git add -p walks through each hunk so you can stage the typo fix alone. git diff --staged (or --cached) shows the index against the last commit, which is exactly the next commit. git restore --staged styles.css copies the committed version into the index, unstaging the file while your edits stay in the working tree. Without --staged, git restore would have overwritten your file.