Git and GitHub: Version Control and Why Undo Is Non-Negotiable

⚠️ Version note: GitHub's website buttons move and get renamed often; git itself (the commands) is extremely stable and hasn't meaningfully changed in years. This lesson leans on the commands, which won't move. Last checked: 24 July 2026. Where the website is involved, it says what to look for.

essay_final_v2_ACTUAL_final_USE_THIS.docx

You know this file. You've made this file. It's what happens when you need to keep old versions "just in case" and have no real tool for it — so you copy, rename, and end up with a folder of near-identical files and no idea which one is current.

That folder is a broken, manual, terrible version of what git does properly. Git is a system that remembers every version of your work, lets you go back to any of them, and shows you exactly what changed between them — without a single _final_v2 in sight.

Here's why this is non-negotiable rather than nice-to-have: the ability to undo, completely and without fear, changes how you work. When you know you can return to any previous state, you experiment freely, you try the risky refactor, you delete the thing that might be needed — because getting back is one command away. Without that safety net, people code timidly, keep dead code "just in case", and lose work. Git is the safety net, and once you have it you won't work without it.

It's also simply how software is built. Every company, every open-source project, every developer uses it. And GitHub — git's home on the internet — doubles as your portfolio (CR-03): a public, browsable record of what you've made and how you work. This lesson gets you from zero to a published repo with real history.

What you'll have at the end

• The mental model: snapshots, not saved files
• The five commands that are 90% of daily git
• A live GitHub repository with a real commit history and a README
• The habits that keep git from biting you

Prerequisite: TC-03. You'll work in the terminal — cd, ls, and the comfort to type commands.

The one idea that makes git click: a commit is a labelled snapshot of your entire project at a moment in time.

Not a saved file — a photograph of everything, with a note saying what changed and why. Your project becomes a timeline of these snapshots:

●────────●────────●────────●────────● (now)
"start"  "add     "fix the  "write   "add
          login"   bug"      README"  feature X"

You can look at any snapshot, compare any two, and return to any of them. That timeline is your project's memory, and it's complete — nothing is ever really lost once committed.

Three places a change lives, which confuses everyone at first, so meet them now:

WORKING          STAGING           REPOSITORY
your files   →    "ready to     →   committed
as they are      snapshot"          (permanent snapshot)
                 (git add)          (git commit)

You edit in the working directory, choose what goes in the next snapshot with staging, then commit to make the snapshot permanent. That two-step (stage, then commit) feels odd at first and turns out to be useful — it lets you snapshot some changes and not others.

✅ Check: you can explain, in one sentence, why a commit is different from just saving a file.