When you opened Claude on a folder back in Level 1, you pointed it at your my-site folder. Claude looked at the files in there and answered questions about them. That folder was a codebase.
The code is the human-readable instructions that make a piece of software work. A codebase is all of that code, organized in a folder. A repository (or repo) is a codebase plus a complete history of every change ever made to it.
In practice, people use repo and codebase almost interchangeably. “Open the repo” and “open the codebase” mean the same thing.
What it looks like
Open a typical repo and you’ll see a folder tree something like:
my-site/
├── README.md ← what this project is, how to run it
├── package.json ← the run command + any libraries
├── index.html ← the homepage
├── about.html ← an about page
├── contact.html ← a contact form
├── styles.css ← the look
├── messages.json ← saved contact messages
├── server/ ← the tiny backend
│ ├── index.js
│ ├── messages.js
│ └── email.js
└── .git/ ← the history (hidden by default)This is my-site, the personal website you’ve been building since Level 1. Other projects are bigger, but the shape is the same: a couple of files that say what the project is and how to run it, the actual code, and a hidden .git/ folder. The names vary. The shape doesn’t.
The .git/ folder is the magic one — that’s where the history lives. We’ll get into it properly in Level 8.
See it for yourself
That tree isn’t a special diagram — it’s just what you’d see if you opened the repo in Claude. When you open a folder in Claude Code Desktop, the file pane down the side shows you exactly this: every file and folder in the project, with a little triangle next to each folder you can click to twirl it open.
Open my-site and the file pane shows a README.md, a package.json, the HTML pages, and a server/ folder. Click server/ open and three small files appear inside — index.js, messages.js, email.js, the files behind the contact form. That clickable tree is the codebase: every instruction that makes my-site run, sitting in plain files in plain folders.
You don’t even have to go clicking around to understand it. Just ask Claude in the chat:
What files are in this project, and what does each one do?Claude reads the folder and answers in plain language — “index.html is your homepage, styles.css controls the look, the server/ folder is the small backend behind your contact form…” The wall of jargon clears the moment you realize it’s just files, and you can ask about any of them.
The thing that trips people up
A repo isn’t just the current state of the files. It’s every version of those files, going back to whenever the project started.
Imagine a Google Doc where you could rewind to any second of any day, see who made every change, and undo any one of them without undoing the others. That’s a repo.
Every time a developer commits a change, the repo remembers it forever. Five years later you can still see exactly what changed on a specific Tuesday in 2021. That’s why teams put code in a repo and not in Dropbox — the history is the point.
The tool that makes this work is called Git. We’ll learn to use it the Claude way in Level 8. For now, just hold this: when someone says “the repo,” they mean the code plus the time machine attached to it.
GitHub, GitLab, Bitbucket
A repo lives in a folder on your computer. But teams need to share repos, so the folder gets mirrored to a hosting service on the internet.
- GitHub — by far the most popular. Owned by Microsoft. Almost every open-source project lives here.
- GitLab — similar, often used by companies that want to self-host.
- Bitbucket — third-place. Often used by teams already on Atlassian tools.
When someone says “send me the GitHub link,” they mean: send me the URL of your repo on GitHub. The code is on your machine and theirs and on GitHub, all kept in sync.
What’s next
Open a repo and you’ll see a wall of file types you might not recognize: .tsx, .py, .go, package.json, requirements.txt. The next lesson decodes them — what’s a language, what’s a framework, and what’s a package?