Picture yourself working on a codebase you've been building for three weeks. You're tired, rushed, and in a moment of carelessness, your finger slips. You accidentally delete a massive chunk of code. Muscle memory kicks in before your brain catches up. You hit save. By the time you realize what happened, the file is gone.
That's a specific kind of modern dread. Now amplify it. Imagine it's not just you. There are ten people editing that same codebase simultaneously. Someone is deleting a core function while someone else is rewriting the interface. Someone is changing the database structure, and you're all overwriting each other in real time. That's not a hypothetical edge case. It's a mathematical certainty without a rigid system in place.
Git is that system.
What a repository actually is
When you type git init in a project folder, something interesting happens that most people don't fully appreciate. Git isn't just creating a folder. It creates a hidden directory called .git inside your project, and that directory is a database. A surveillance apparatus that watches every file in your project from that moment forward, mapping a complex mathematical tree of the project's entire history.
It's less "a folder on a server" and more "a local database that tracks cryptographic hashes of your work." Every file, every modification, every deletion, recorded and indexed.
Commits: save points with mandatory labels
The fundamental operation in Git is the commit — a permanent snapshot of your code at a specific point in time. Think of it as a save point in a video game: before you attempt to refactor a fragile piece of legacy code, you lock in your progress so you have a baseline to retreat to if everything breaks.
What trips people up is the deliberate two-step process. You can't just "save everything." First, you stage specific files with git add. Then you commit with git commit. Why the friction?
Consider how developers actually work. You spend four hours writing code and touch seven different files. Three of those contain the brilliant new feature you were asked to build. The other four contain messy debugging statements, temporary hacks, and broken experiments you used to test it. You don't want to save the garbage into the official permanent history of the project.
Think of staging as photography. The final commit is snapping the photo. The staging area is where you arrange the subjects, adjust the lighting, and make sure nobody is blinking. You use git add to carefully place only the three clean, finished files into the frame. The messy ones stay out of the shot. Then you write a label on the back of the Polaroid explaining exactly what the photo captures.
That label matters more than it seems. A Git repository is a complex web of interconnected snapshots. When you or your team look back at the history a year from now, trying to find when a specific bug appeared, you're reading the commit messages. "fixed thing" and "stuff" are not navigable. "Refactored authentication middleware to handle expired tokens" is.
Branches: parallel universes that cost almost nothing
Branches solve the multiplayer collision problem. When you want to build a new feature, you don't build it in the main timeline. You create a parallel universe with git checkout -b my-feature, a completely isolated version of the codebase.
Here's what surprises most people: a branch is not a copy of your project. If your codebase is 2 gigabytes, creating a branch doesn't duplicate those 2 gigabytes. A branch is literally a 41-byte text file containing a pointer to your current commit. Creating it costs almost zero memory. It just creates a new sticky note that says "from this commit forward, record new snapshots on this path."
You can completely destroy the code in your branch. Delete core files. Set the whole thing on fire. The main version of the codebase, which the rest of your team is working on, remains completely isolated and intact. Experimental fearlessness, at essentially zero cost.
GitHub: the cloud synchronization layer
Everything described above happens locally, inside that hidden .git directory on your machine. GitHub is where the network layer enters. If Git is the local database, GitHub is the centralized master server that holds the source of truth for the entire team.
git push origin main sends your commits from your machine to the central repository. git pull brings the latest changes from everyone else to your machine.
The protocol: pull before you start work. Branch off. Make commits. Push when done. Merge into main. The workflow is airtight for a reason: it's designed to prevent the specific kind of collision that would otherwise be a mathematical certainty.
When AI takes the wheel
Stefan Sånnell's original piece for this bootcamp ends with a shift worth thinking about. An AI tool like Claude Code can abstract the entire Git workflow. Instead of typing the sequence of commands yourself, you describe the intent in plain English: "create a new branch called fix-login-bug and commit my changes."
The AI analyzes your working directory, figures out which files have been modified, creates the branch, stages the relevant files, generates a descriptive commit message based on the actual code changes, and executes the commit.
That solves the 2 AM meaningless commit message problem. It democratizes the tool for people who don't have a decade of command-line muscle memory.
But there's a tension worth sitting with. Git isn't just syntax — it's state management. It's the architectural foundation of your team's entire collaboration history. If the AI misinterprets your intent and stages files that contain sensitive API keys because you vaguely said "commit everything" and you didn't review the git add step, that's a catastrophic security failure.
The mental model still matters, even if you're not typing the commands. You're the manager delegating tasks to a skilled assistant. You need to know what to ask for, and you need to be able to recognize when something went wrong. Whether we're architects or passengers depends entirely on how well we understand what's happening underneath.