Git

Trouble starts the moment more than one person edits the same file. The old fix was to put dates and names in the filename. A folder that holds spec_0312.docx, spec_0312_edit.docx, and spec_final_noa.docx side by side gives you no way to tell which one is current without opening all three.

With code the approach collapses faster. Two people edit the same file, both upload to a shared folder, and whoever saves second wipes out the first person's work completely. The person who got overwritten usually finds out days later, when something they wrote is missing.

That produced the first generation of tools, which kept the history on one server. To edit a file you locked it, and you released the lock when you were done. Overwrites stopped, but the server became a gate on every piece of work. Lose the network and you can't even read past history, let alone save a change. If someone locks a file and goes home, that file belongs to nobody until the next morning, and the usual workaround was to copy it, edit the copy, and paste the result back in afterwards — which is exactly the overwriting the lock was meant to prevent.

Git changed direction by refusing to keep the history in one place. Cloning a repository copies not just the latest files but every record made so far. You can dig through a three-year-old change and commit a new one from a plane with no connection, and if the server burns down, there are as many complete copies as there are people on the team.

Four specific problems go away, each matching one of the frustrations above.

1. Who changed what, when, and why stays on the record. Every commit — one bundled change, saved as a point in history — carries both the modified lines and a message explaining them. When a screen breaks, walking that file's history backwards narrows the cause to a single commit in a few minutes.
2. People working on different things at the same time stop blocking each other. Give everyone their own branch, a line of work split off from the mainline, and a half-finished payment feature doesn't hold up anyone else's release.
3. There is far less for a human to reconcile. A merge, which brings two diverged lines back together, combines edits to different lines automatically. People only get involved in a merge conflict, where both sides changed the same line and the machine has no basis for choosing.
4. Undoing gets cheap. If yesterday's release caused an outage, reverting that one commit is a single command. When reversing a change is cheap, trying one gets cheap too.

One important side effect follows. Once history is cheap and safe, a team can afford to put a person in the path before anything merges. That is where the pull request — a request to merge your branch into the mainline — and the code review a colleague writes on it come from. Without the assumption that a bad merge can be undone, that much ceremony would be too expensive to sustain.

Almost nobody starts a new project on something other than Git today, but the alternatives are real, and they fall into three groups.

The first is the centralized tools that keep history only on a server. Subversion is the best-known, and Perforce is still common in game development. Large files are the reason they survive. In a repository holding thousands of 3 GB 3D model files, copying the entire history onto every machine is not workable. Locking a file to block simultaneous edits outright is also useful for formats that cannot be merged line by line at all.

The second is Mercurial, which is distributed in the same way Git is. The structure is the same, full history copied locally, and the range of things it can do is nearly identical. Many people found its command set tidier, but libraries, hosting, and deployment tooling all concentrated around Git, and the surrounding ecosystem settled the contest rather than any technical margin.

The third is using a file-sync service in place of version control. A shared drive does keep old versions, so there is history of a sort. What it lacks is merging. When two people edit one file it either picks a winner or leaves two copies; it will not weave the changes together line by line.

Set those side by side and the choice is clear enough. Text-based code edited by several people means Git. A codebase dominated by large binaries that can't be merged still points toward a central server and locks, and plenty of game studios run both at once — Git for the game code, Perforce for the art assets.

"Can you check the history and see when that code started looking like this?"

An ask to trace back through the record and find which commit introduced the problem line.

"Cut a branch, work there, and get it reviewed before it lands."

Stay off the mainline, work on a split-off line, and have a colleague check it before merging.

"Yesterday's release had a problem, so I reverted just that commit."

Rather than rolling the whole product back a version, only the one bad change was undone.

At Pagedeck every new hire walks through this loop in their first week. The first task Theo hands a new engineer is changing one line of help text. Cloning the repository, cutting a branch, editing the line, committing it, opening a pull request, getting a review, and merging all fit inside that one task.

The triviality of the edit is deliberate. What's being learned is the procedure, not the code, and a one-line change means a review that takes thirty seconds rather than a day. Somebody who has been around the loop once takes the same route the following week when the file in question is payment logic.

Treating Git and GitHub as the same thing is the most common confusion, and it's an understandable one, since people rarely meet them separately. Onboarding guides usually open with creating a GitHub account, and in conversation "I pushed it to Git" and "I pushed it to GitHub" get used interchangeably.

In fact Git is the tool, and GitHub is a service that hosts the repositories the tool produces so a team can work on them together. Pull request screens and review comments are things that service adds, not features of Git itself. Fusing the two in your head leads to believing you can't commit while offline, or to reading a discussion about switching hosting providers as a discussion about replacing the tool. Since the history already sits on every machine, moving providers is closer to pushing another copy to a different server.