Files, versions, and git

Open the desktop of any computer that has ever produced a serious document. Eventually you find this folder.

Final.docx
Final_v2.docx
Final_FINAL.docx
Final_FINAL_actually_use_this_one.docx
Final_FINAL_Sept2024.docx
Final_FINAL_Sept2024_with_Maria_comments.docx

Some version of this folder is a universal human experience. It exists because we all share a basic need, to keep our work but also to keep older copies of our work, in case the current copy turns out to be worse than the older one.

Software has the exact same need. The difference is that engineers built a tool for it instead of relying on filenames, and that tool is called git.

Code is just files. Lots of them.

Before we talk about git, let's settle what code actually is. It is a folder. The folder has files in it. The files have text in them. That's it.

When you hear codebase, or repo, or repository, what is meant is a folder of files containing the text of a program, along with whatever supporting things the program needs to run (images, configuration, instructions for how to install).

Open any open-source project on GitHub and click around. What you will see is a familiar shape: folders, sub-folders, files with names like index.js or Button.tsx or README.md. Some of those files are code, some are documentation, some are configuration. All of them are text.

You will never need to read them. You will need to know that this is the shape of a codebase.

What git is, in one sentence

Git is undo for an entire project.

That is the whole pitch. Imagine the undo button in your word processor, except instead of remembering the last fifty keystrokes, it remembers every change ever made to every file in the folder, by anyone, forever.

That is git.

Why this matters: because once you have undo for a whole project, you can be brave. You can try a risky change knowing that you can always go back. You can hand the folder to a colleague knowing they can experiment without breaking what you had already done. You can branch off into a "what if I redesigned this whole part" experiment, and if it turns out to be a bad idea, you delete the branch and your main work is untouched.

Nothing in modern software works without git or something very much like it. When AI tools tell you to commit your changes or create a branch or pull the latest, this is the system they are talking to.

The mental model, no commands

Three concepts and you have enough to operate.

Commit. A snapshot of the folder at a specific moment in time. You take commits. Each one comes with a small note ("changed the home page heading") that explains what is in it.

Branch. A parallel timeline. You can start a new branch off your main work, make a series of commits on the branch (try something out), and either merge the branch back into main (you liked the result) or throw the branch away (you didn't).

Pull and push. When multiple people are working on the same project, pull means "give me the latest commits from the team" and push means "send my commits up to the team."

That is enough mental model to read every AI-tool message about git for the rest of your career. You do not need to memorize commands. The AI knows the commands. You need to know the shape.

Why this lesson exists at all

Two reasons.

First, because git is one of those technical words that, undefined, makes people feel like they are at the wrong party. It is not. Git is a very useful, slightly grumpy tool that handles a problem you already have intuitively (multiple versions of the same work) in a more principled way than naming files _FINAL_actually.

Second, because when you build anything more serious than a single experiment, the version control is what separates "I have a prototype" from "I have something I can keep working on without breaking what I had yesterday." Day 19 will come back to this when we talk about guardrails, because the moment you forget to commit is the moment your laptop battery dies.

A small note on GitHub versus git

These are two different things and people use the names interchangeably.

Git is the tool that keeps the history.

GitHub is a website (owned by Microsoft) where people store their git histories in the cloud and collaborate with each other. There are alternatives (GitLab, Bitbucket), but GitHub is by far the most common.

When AI tools talk about pushing to GitHub, they mean "send my local commits up to a remote copy of the project that lives on GitHub's servers." That is the remote sense of Day 3 applied to git.

Forward references

Day 7 closes Week 1 by tying together environments, deployments, and the "it works on my machine" problem. From Week 2 onwards, every lesson assumes you have a working mental model of code-as-files and version-control-as-undo. If you skipped to Day 6 directly, going back to Day 3 will pay you back tenfold.

Day 6 wrap

The thing you can now say plainly. Code is just files in a folder, and git is undo for the whole folder over time. Modern software relies on git the same way modern writing relies on the save button.

The thing you can now do. When an AI tool tells you to commit, branch, push, or pull, hold the mental model of snapshots and parallel timelines, and let the tool handle the syntax.

The guardrail to remember. The "Final_FINAL_actually_use_this" folder is what happens when a team does not use git. Don't ship anything serious without it.

See you on Day 7, the closer of Week 1.