Code of the Day
BeginnerGit & Version Control

Version control, conceptually

What commits, branches, and merges really represent — and why history is a tool for thinking.

FundamentalsBeginner9 min read
Recommended first
By the end of this lesson you will be able to:
  • Explain what a commit, branch, and merge represent
  • Describe why a clean history helps you (and reviewers) think
  • Understand how version control enables safe collaboration with people and agents

is "undo" for an entire project, across its whole history, shared between everyone working on it. The dominant tool is git, but the concepts outlive any tool — and they're what matter here. Get the mental model and the commands stop being magic incantations.

Commits: snapshots over time

A is a saved snapshot of your whole project at a moment, with a note explaining what changed and why. String commits together and you get a timeline you can travel along: see what the code looked like last Tuesday, find exactly when a bug appeared, undo a change from a week ago.

A good commit is small and focused — one logical change — with a message that says why, not just what. "Fix off-by-one in pagination" tells a future reader (often you) something the diff alone can't.

Branches: cheap parallel universes

A branch lets you diverge from the main line and work on something —a feature, an experiment, a fix — without disturbing the stable version. It's a parallel universe of your project that's almost free to create. Try a risky idea on a branch; if it works, keep it; if not, throw the branch away and the main line never knew.

Merges: bringing universes back together

Merging combines the changes from one branch into another. When two branches changed different things, git stitches them together automatically. When they changed the same lines in conflicting ways, you get a merge conflict — git honestly admitting it can't decide, and asking you to. Conflicts feel scary at first but are just "two people edited the same sentence; which do we keep?"

Why this is a thinking tool

History isn't bureaucracy — it's leverage:

  • Fearless change. You can refactor boldly, knowing every prior state is recoverable.
  • Bisection. When a bug appears, you can binary-search the history to find the exact commit that introduced it (more on this in debugging).
  • Review. A clean series of small commits is a story a colleague — or you, in six months — can actually follow.

Collaboration, including with agents

Version control is what lets many people (and AI agents) work on the same code without chaos. An agent's changes land on a branch; you review the diff, run the tests, and merge only when satisfied. The history records who changed what and why, which is exactly the accountability you want when some of the "who" is a machine.

The habit that makes git pleasant: commit small, commit often, and write the message for the person who'll read it later. That person is usually you.

Where to go next

That completes the beginner mental models. From here, branch into a language track to practise syntax, or step up to Systems & Structure to learn how whole systems fit together.

Finished reading? Mark it complete to track your progress.

On this page