A code repository is a central place where software gets built and stored. It holds the code itself, the documentation that goes with it, and a complete history of every change anyone has ever made to it.
What do we mean by "code"?
Computer code is the text that developers write and then turn into computer programs. The web browser you're reading this in is a program. So is your email client, your phone's camera app, and the software running the self-checkout at the grocery store. There are many browsers to choose from, and likewise many languages a program can be written in. But whatever the language, it starts as text that somebody typed.
Why store it all in one place?
Three reasons, mostly.
- To track changes. People make mistakes. Ideas that sounded good on Monday turn out to be bad by Thursday. When something breaks, the first useful question is when did this get introduced? A repository answers that, which makes the change far easier to fix or undo.
- To collaborate. Large projects involve a lot of people, and each of them is usually working on one small piece of something much bigger. Those pieces have to fit together at the end. A shared repository is what keeps everyone building the same thing.
- To hold the documentation. Not just the documentation written for other developers, but often the documentation that you, the end user, eventually read. (The notes developers leave for each other are usually much worse than whatever ships with the product.)
Where does the repository live?
In most cases, two places at once — and that's the part that surprises people.
There's a master copy that lives somewhere everyone can reach it, usually on a service like GitHub. And then each person working on the project has their own full copy sitting on their own computer. Not a partial copy or a shortcut to the real one. The whole thing.
That means a developer can work on a plane with no Wi-Fi, get a bunch done, and hand it over later when they're back online. It also means that if the shared copy is ever lost, a dozen people are still walking around with complete backups in their laptop bags.
Some older setups keep only the one central copy and everyone connects to it to work. That still exists, but the two-copy arrangement is what most projects use now.
What do people actually do with it?
The work comes down to a small number of moves that repeat all day long. They have odd names, but each one is simple.
You start by getting your own copy of the project, the files, plus the whole history of how they got that way.
As you work, you save your progress in chunks. Not the way you'd save a Word document every few minutes, but deliberately: you finish a piece of work, and you save it along with a short note explaining what you did. "Fixed the button that wasn't clickable on phones." Those notes pile up into a written record of the project's entire life. Months later, when something is behaving strangely, someone can scroll back and find the exact day it started.
When you're happy with your work, you send it up to the shared copy so everyone else can use it. And because other people have been doing the same thing all week, you'll regularly pull their work down into yours, so you're building on the current version of the project instead of last Tuesday's.
Trying things without breaking things
There's one more idea worth knowing, because it's the one that makes the whole system feel less nerve-racking.
Before someone tries something risky, they can split off a private version of the project to experiment in. The main version carries on untouched. If the experiment works, they fold it back in. If it doesn't, they throw the whole thing away and nothing is lost, no apology needed, no damage done.
Occasionally two people change the same thing at the same time, and the system can't tell which version should win. It stops and asks a person to decide. That sounds like a disaster, but it's routine, it happens most weeks on most projects, and sorting it out is just part of the job.
