Part IX gave you the evidence loop: inspect the current state, make a small change, check what actually happened. That loop answers "is this change good?" Git answers the question right behind it: "what did the project look like before this change?"

Without that answer, every AI session starts from amnesia. With it, the project has a memory that outlives any single chat window.

The three things people confuse

Say these plainly, then use the real terms:

• A project folder is the files on your computer right now: Markdown docs, code, tests, images, config.
• Git is the local history system inside that folder. It records what changed, when, and in what order — even with no internet.
• GitHub is an online host for Git repositories. It holds a shared copy, lets people collaborate, and adds pull requests, issue tracking, and integrations.

Git works without GitHub. GitHub does not replace Git.

That distinction matters because beginners often treat GitHub as magic backup. It is not. GitHub can only receive the history you deliberately record and push. If you never commit, there is nothing for GitHub to save.

For durable concepts and command explanations, the canonical reference is the Pro Git book.

What a repository actually is

A repository is a project folder whose file history Git tracks.

Technically, that tracking lives in a hidden .git directory at the top of the folder. You do not edit .git directly. Think of it as the project's memory vault: Git manages it, you interact with it through ordinary commands like status, diff, commit, and branch.

A repository can hold everything the project needs to be understood later:

research-dashboard/
  README.md
  PRD.md
  src/
  tests/
  public/
  .git/

README.md orients a newcomer. PRD.md records what the product is supposed to do. src/ holds application code. tests/ holds checks. public/ holds static assets. .git/ holds history.

That is why Class 41 is the canonical Git home for this course. Part III and Part IX previewed repositories and branches so you could work safely. Here you learn the complete loop.

Follow the research dashboard through this part. Today it is a folder with a first clickable prototype. Over the next three lessons it gains source dates, a watchlist, and a scheduled refresh — and Git remembers every step from prototype to product.

Local versus remote, without hand-waving

Here is the whole geography in one diagram:

Your computer: project folder + Git history
          ↓ push
GitHub: remote copy, collaboration, pull requests, review
          ↓ optional integration
Preview / deployment service: builds a version from selected GitHub changes

Your computer is where work happens. GitHub is the remote — a connected copy of the repository hosted somewhere else. A preview or deployment service can then build a runnable version from selected GitHub changes, but it is a third layer, not automatic.

Origin is simply the conventional name for the default remote. When a tutorial says "push to origin," it means "send committed history to the default GitHub copy." There is nothing mystical about the word. It is a nickname.

Two ways to begin:

• Clone starts from an existing remote project. You copy a GitHub repository down to your computer, history included.
• Initialize starts tracking a local folder that Git does not yet follow. You turn an ordinary folder into a repository, then optionally connect it to a new empty GitHub remote.

Use clone when the project already exists on GitHub. Use initialize when the project starts on your machine.

Safe first moves: inspect, don't change

A beginner's most valuable Git skill is inspection. Before you edit, initialize, commit, or push anything, learn to answer five questions:

1. Where am I? (which folder) 2. Is Git initialized here? (is there a .git vault?) 3. Which branch is active? 4. Is the working tree clean? 5. Is a remote connected, and to where?

Clean has a precise meaning: no uncommitted local file changes. It does not mean bug-free. A project can be clean and broken, or dirty and brilliant. Clean only tells you whether the current folder matches the last recorded checkpoint.

Concept first, commands second. Here is the actual inspection set:

pwd
git rev-parse --is-inside-work-tree
git status -sb
git branch --show-current
git remote -v

Read them as sentences: show me the folder, confirm Git tracks it, summarize branch and dirtiness, name the active branch, list connected remotes. If git status reports "nothing to commit, working tree clean," the folder matches history. If it lists modified or untracked files, someone — you or an AI — changed something since the last checkpoint.

Practice this before you need it. When an agent says "I updated the dashboard," your first move is not applause. It is git status.

Why AI builders need this more, not less

A careful human might edit five files in an afternoon. A coding agent can edit fifty files in five minutes — fast, confident, and occasionally wrong in ways that sprawl across the project.

That is exactly why history matters. Without Git, a big AI edit is a rumor: something changed somewhere. With Git, it is inspectable and reversible: which files changed, what the diff was, what the project looked like before, and how to return.

The rule for this whole class: never let an agent modify or initialize a repository you cannot first describe. Inspect-only comes before edit permission.

The neighborhood-events version

The same geography fits the lighter example. The events finder folder holds a page, a data-source note, and tests. Git tracks how "show three hardcoded events" became "fetch this weekend's events from an approved source with an empty state." GitHub holds the shared copy the reviewer sees. The preview service builds a clickable version from a branch. Three layers, three jobs.

Exercise: write REPO-ORIENTATION.md

Pick one non-sensitive project folder. Ask an AI to inspect only — explicitly forbid modifying, initializing, committing, or pushing. It should report: repository location, whether Git is initialized, current branch, uncommitted changes, and remote connection.

Then write REPO-ORIENTATION.md in that folder:

# Repo orientation

- Location: ...
- Initialized: yes / no
- Current branch: ...
- Working tree: clean / dirty (list uncommitted files)
- Remote: origin → <URL or "none connected">

Git is ... GitHub is ...

The last line must explain the difference in one sentence, in your own words.

Check your understanding

• An agent says "your work is backed up on GitHub." You have never committed. Is it backed up? Why not?
• git status says "working tree clean." Does that prove the app works?
• When would you clone, and when would you initialize?

Finish line

You are done when REPO-ORIENTATION.md exists with the location, branch, remote status, and a one-sentence Git-versus-GitHub distinction.

Verify: re-run the five inspection commands and confirm every line in your file matches live output. If the tree is dirty, name the changed files — do not commit them yet. That is Lesson 41.2.

Common failure mode: treating GitHub as automatic backup while never committing. The dashboard author chats for a week, pushes nothing, loses a folder, and discovers GitHub holds last month's prototype. Recovery: GitHub only receives committed history you push. Make one small, intentional checkpoint first — next lesson shows how.