Many People, One Codebase
Pageturn's code doesn't live on Maya's laptop alone. It sits in one shared place that the whole team works from — Maya, and the other developers who add features and fix bugs alongside her. The trouble starts the moment two of them open the same file.
If Maya and a teammate both edit the sign-up page at the same time, whoever saves last can quietly erase the other's work. You need a system that tracks who changed what, and keeps two people's edits from colliding. That system is called version control — software that records every change to the code over time.
One shared codebase
All of Pageturn's code — every file that makes the app work — lives in one shared place the whole team draws from. This is the codebase: the single source of truth for what Pageturn actually is. When Maya wants to add a feature, she starts from that shared code, not from a private copy that has quietly drifted out of date.
That single source is the point. If everyone worked from their own scattered copies, there would be no answer to a simple question: what is the real, current Pageturn right now? One shared codebase gives that question one answer.
When two people touch the same file
Now picture Maya and another developer both editing the sign-up page on the same afternoon. Maya saves her version. A few minutes later her teammate saves theirs — built from the older code, with no idea Maya had changed anything. Their save overwrites hers, and her work simply vanishes.
This is the collision problem, and on any team with more than one person it isn't rare — it's constant. Passing files around by email or copying folders back and forth only makes it worse, because then nobody can even tell which copy is the real one.
What version control records
Version control solves this by keeping a record of every change made to the code. Not just the latest state — every edit, tagged with who made it, what they changed, and when. Nothing is silently lost, because every version is remembered.
Because the system knows that history, it can also notice when two people changed the same lines and ask a human to sort it out, instead of letting one save quietly destroy the other. We'll see exactly how that plays out when we reach branches and merging later in this chapter.
The repository
The place where all of this lives — the code together with its complete history — is called a repository, or repo for short. Pageturn has one repo, and it's the team's shared home base: copy it onto your machine and you get the project plus the full story of how it got here.
From here on we'll just say repo. It's where the rest of the pipeline begins: every time we build, test, or deploy Pageturn in later chapters, it starts from a change landing in this one repository. The software that makes all of this work is called Git, and you'll use it hands-on in Git for Beginners.
- "Version control is just backups." A backup is a copy you fall back to if disaster strikes. Version control records every change as you go — with who and why — and lets many people work on the same code at once. A backup does none of that.
- "Saving the file is version control." A normal save overwrites the previous version, and the old one is gone. Version control keeps every saved state as a labeled point you can return to.
- "Only one person can work on the code at a time." The opposite — the whole reason version control exists is to let many people work on the same codebase at once without losing each other's work.
- "A repo is just a folder of files." A repo is the files plus their entire history — every change ever made — not only the current snapshot you happen to see.
- The repository is where the whole pipeline begins: every build, test, and deploy in later chapters is set off by a change landing here.
- "Repo" is everyday vocabulary on any software team — you'll hear "it's in the repo" constantly, and now you know exactly what that means.
- The collision problem is real on teams of any size; understanding it explains why developers never just email code around to each other.
- This is the first step of the Git strand — the tool that does all of this, which you'll use hands-on in Git for Beginners.
Knowledge Check
What problem does version control mainly solve?
- It stops people editing the same code from losing each other's work
- It makes the app run faster for the people using it
- It writes all of the code automatically so the whole team doesn't have to
- It permanently deletes old versions to save space
What is a repository?
- The project's code together with its complete history of changes
- A single backup copy kept in case the code is lost
- The newest version of the code, with older ones discarded
- A folder on one developer's own laptop that only they can ever open
Why isn't simply saving a file the same as version control?
- Saving overwrites the old version, while version control keeps each one
- Saving is slower than letting version control do it for you
- Saving can only be done by one developer on the whole team
- Saving stores the file in the cloud and version control stores it locally
You got correct