learn.gisketch Full-Stack Engineering with AI Assistance
0 / 91
Week 2 · Day 13 of 91

Git snapshots and meaningful commits

HTML, CSS, Git, and the First Website

Objective

Record small, understandable changes and inspect history.

HTML is the mechanical structure, CSS is the physical layout and finish, and Git is the revision history for every design change.

  • working tree, staging, commit
  • git status and diff
  • meaningful commit messages

Why this matters

You have five days of work in profile-site and exactly one copy of it. One bad edit and it is gone. Today you put it under Git — installed on Day 2, met as a concept on Day 1 — and record your changes as small, labelled, reversible snapshots.

The habit matters more than the commands. Ten commits that each say what they changed is a document you can read a year from now. One commit called "stuff" is a black box.

The three places a change can be

Git confuses beginners because a change passes through three places on its way into history. Learn these three names and most of Git stops being mysterious.

  1. The working tree — your actual files on disk, as your editor sees them. Save a file and the change is here and nowhere else.
  2. The staging area (also "the index") — the changes you have chosen to include in the next snapshot. git add moves a change here. Nothing is recorded yet.
  3. The repository — the permanent history, inside the hidden .git folder. git commit writes everything currently staged as one snapshot, with a message and your name.

Working tree → git add → staging area → git commit → repository. That is the whole flow.

The staging area exists so a commit can be smaller than everything you did. Fix a typo and rewrite the nav in the same hour, and you can commit them separately — two honest entries instead of one muddled one.

Bench, parts tray, released revision

The working tree is the bench you are soldering on — anything can be half-done. The staging area is the tray where you set out exactly the parts for the revision you intend to release; putting a part in the tray releases nothing. The commit is the signed-off revision: dated, attributed, and filed in the archive where it cannot quietly change.

Starting a repository

From inside profile-site:

git init

Initialized empty Git repository in /Users/you/fullstack-journey/profile-site/.git/

That hidden .git folder is the repository — the whole history lives there, and deleting it deletes your history while leaving your files alone.

Git may report the default branch as master and suggest configuring it. The current convention is main:

git config --global init.defaultBranch main

git status and git diff

git status is the command you run constantly. It reports the state of your working files: which tracked files have changed, and which files Git does not know about at all.

git status

On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	index.html
	styles.css

nothing added to commit but untracked files present (use "git add" to track)

Untracked means Git has never been told to watch that file. Tracked files you have edited appear as modified:. Git even prints the command you probably want next — read those hints.

git status tells you which files changed. git diff tells you what changed inside them:

git diff

diff --git a/index.html b/index.html
index f5a8e9c..bbef1ef 100644
--- a/index.html
+++ b/index.html
@@ -1,3 +1,4 @@
 <!doctype html>
 <html lang="en">
+  <body></body>
 </html>

Lines starting with + were added, - removed, unmarked lines are context. git diff shows changes not yet staged; git diff --staged shows what is staged and about to be committed. Reading the diff before committing is the best habit in this lesson — it is how you catch the debug line you meant to delete.

Messages that are worth reading

A commit message is written for whoever reads history later, usually you.

  • A short subject line, about 50 characters, in the imperative: "Add contact form", not "added contact form" or "changes".
  • Say what changed and why, not how. The diff already shows how.
  • One logical change per commit. If your subject needs "and", that is usually two commits.

Compare Fix stuff with Fix broken image path on About page. The second tells you whether it is the commit you want without opening it.

A lab notebook, not a save button

Ctrl+S saves. A commit is the notebook entry beside it: what changed, why, and when. You would not write "did things" in a lab notebook and expect to reproduce the experiment.

Keeping junk out

Some files should never be committed: editor and OS clutter, downloaded dependencies, anything secret. List them in .gitignore at the top of the repository:

.DS_Store
node_modules/
*.log
.env

Git then ignores those paths. .DS_Store is a macOS Finder file; node_modules/ is downloaded code arriving in Week 5 that must never be committed; .env is where secrets live later. Commit the .gitignore file itself — it is part of the project.

Committed secrets do not go away

Deleting a password in a later commit does not remove it from history — every earlier commit still holds it, and once the repository is pushed (Day 14) it is public. Add .env to .gitignore before the file exists.

Walkthrough: your first three commits

In profile-site, with git init already run:

git status
git add index.html
git commit -m "Add semantic profile page structure"

[main (root-commit) 881e335] Add semantic profile page structure
 1 file changed, 3 insertions(+)
 create mode 100644 index.html

881e335 is the start of the commit's unique ID; root-commit appears only on the first one. Now the second:

git add styles.css
git diff --staged
git commit -m "Add stylesheet with card and typography rules"

Then stage everything remaining and make a third:

git add .
git commit -m "Make project cards responsive at small widths"

git add . stages every change in the current folder and below — convenient, and worth pairing with git status first so you know what you just swept in. Now read the history:

git log --oneline

91ebfb8 Make project cards responsive at small widths
881e335 Add semantic profile page structure

Look inside one commit

Run git show 881e335, substituting your own ID. You get the message, author, date, and full diff of that snapshot — a searchable, readable record instead of a pile of files.

`git reset --hard` destroys uncommitted work

It throws away every uncommitted change in your working tree, permanently and without asking. Anything not yet committed is unrecoverable. To undo edits to one file use git restore <file>; to see what you would lose, run git status and git diff first. Experiment with reset only in a throwaway repository — mkdir /tmp/git-scratch && cd /tmp/git-scratch && git init — never in profile-site.

Your turn

  1. Run git init in profile-site if you have not, then git status and read every line.
  2. Create .gitignore with the four entries above. Run git status again — the ignored files are gone from the list.
  3. Make at least three focused commits, each one logical change: the HTML structure, the stylesheet, then the responsive layout. Before each, run git diff --staged and confirm you can explain every changed line.
  4. Write each message as an imperative subject under about 50 characters.
  5. Run git log --oneline and check the history reads as a story from bottom to top.
  6. Make one small edit — a typo in your footer — then git status, git diff, stage, and commit it as a fourth commit. That is the full loop, unaided.
  7. Run git show on your first commit and confirm no .DS_Store or stray file sneaked in.

You are done when

git status reports a clean working tree, git log --oneline lists at least three commits whose subjects you can read as a description of the week, and nothing generated or secret is tracked.

Reviewer mode, before you commit a large change

Skeptical reviewer mode: hand over the work and ask for concrete defects with evidence — specific findings pointing at specific lines — not praise, not a rewrite. Paste your git diff:

"Review my git diff and suggest how to split it into focused commits. Do not run Git commands for me."

That last sentence matters. You run the commands, because the history is yours to defend.

Common pitfalls

  • Committing without staging. git commit records only what is staged; skip git add and the commit is empty or missing files. git status before every commit prevents this.
  • One giant commit at the end of the day. Easiest habit to fall into, least useful history. Commit when one thing works.
  • Vague messages. "update", "fix", "wip". Future you will open every one of them.
  • Committing node_modules or .DS_Store. Thousands of junk files in your diffs. Write .gitignore first.

Verify it yourself

Open today's reference, the Pro Git book, and read "Recording Changes to the Repository" in chapter 2.

  1. Pro Git gives a file lifecycle with more states than this lesson named, including staged and unmodified. Draw its state diagram and mark where git add and git commit move a file.
  2. Find what Pro Git says about git commit -a. What does it skip, and why is that sometimes a bad idea?

Write both answers into notes/day-13.md, and commit that file.

The hour

  1. 0–5 min Recall

    Without notes, state yesterday’s main idea and one unresolved question.

  2. 5–20 min Learn

    Read only the listed concept notes and official reference sections needed today.

  3. 20–48 min Build

    Initialize Git, create at least three focused commits, and inspect the log and diffs.

  4. 48–55 min Explain and verify

    Run the result, inspect evidence, and explain the data/control flow in your own words.

  5. 55–60 min Quiz and commit

    Complete the quiz, record one lesson, and commit the verified change when applicable.

What to hand in

Deliverable

A repository with clear commit history and no generated junk committed.

Working with AI today

AI as skeptical reviewer

Provide existing work and ask for concrete defects, risks, missing tests, and unsupported assumptions—not praise.

Review my git diff and suggest how to split it into focused commits. Do not run Git commands for me.

References

End-of-day quiz

Q1 What does git status primarily show?
Q2 Which result best proves today’s work is complete?
Q3 What should an AI code review primarily produce?

Explain-back gate

Pass the quiz above to unlock completion.

Quiz + explain-back checks required.