What Is GitHub? A Plain-English Explainer

The short version

• GitHub is where the real, running code for a website or app lives.
• Think of it as a shared binder with a complete history. Every change anyone ever made is saved, labeled, and can be undone.
• You do not need to know how to code to understand what it does for a business. You just need to know what problem it solves.
• This is the first of a short series on how we actually build People in the Loop. The next posts cover branches (dev vs main) and environment variables in Netlify.

The problem GitHub solves

Picture the worst version of a shared document. Five people are editing it. Nobody knows who changed what. Someone overwrites someone else's work by accident. There is a file called "final," a file called "final_v2," and a file called "final_ACTUAL_use_this_one." You have lived this, even if you have never opened Figma or written a line of code in your life.

Now picture a shared document that remembers everything. Every change is saved as its own entry, with a note about what changed and who changed it. You can look back at any point in time and see exactly what it looked like. If someone breaks something, you can undo just that one change, cleanly, without losing anything else. That is what GitHub is, but for code instead of documents.

What GitHub actually is, in plain terms

Q: What is GitHub?

GitHub is a place to store code and track every change made to it over time. Developers call the whole project a "repository," or "repo" for short. Every saved change is called a "commit." Each commit has a note attached explaining what it did.

Q: Do I need to understand code to understand GitHub?

No. You need to understand the shape of the problem it solves: keeping a complex, constantly-changing project organized, reversible, and honest about its own history. That is a business problem before it is a technical one.

Q: Is GitHub the same thing as the website itself?

No. GitHub holds the instructions for the website, the actual code. A separate service (in our case, Netlify) reads those instructions and turns them into the live site people visit. GitHub is the recipe. The live site is the finished dish.

The whole point of a system like this is that nothing is ever truly lost, and nothing ships by accident. Every change is visible, on purpose, and undoable.

Why we use it at People in the Loop

Once our brand system moved out of Figma and into real building (see the previous post in this series), GitHub became the actual home base. Every change to peopleintheloop.app, a new page, a fixed bug, a new feature, gets saved as its own commit, with its own note, in the project's full history. Nothing changes on the live site without a record of exactly what changed and why.

That matters more as a team grows past just one person. Right now that team includes me and Claude, working through Claude Code, plus the record GitHub keeps of every session's work. Later, it means a real developer, or a second Claude session working in parallel, can pick up exactly where things left off, with the full history in front of them, instead of guessing.

What is coming next in this series

Knowing what GitHub is only gets you halfway. The next real question is: how do you make changes without breaking the site everyone is already using? That is what "dev" and "main" branches are for, and it is genuinely one of the more useful ideas in here for anyone running anything live, not just a website. That is the next post.

After that: environment variables, the settings and secrets that change depending on where your code is running, and why you never want those hardcoded into the code itself.

Key terms glossary

GitHub: a place to store code and track every change made to it over time.

Repository (repo): the full project, all its code and its complete history, stored in one place.

Commit: one saved, labeled change to the code.

Netlify: the service that takes the code from GitHub and turns it into the live, running website.