P-2.3 Version Control: Commits, History and Undo

What this is and why it exists

Version control is the highest-value tool a programmer learns. It is usually taught as four commands to memorise, which is why so many people use it nervously for years.

What it actually gives you is the ability to experiment without fear. Any state you recorded can be recovered exactly. That changes how you work, not only what you type.

One idea makes almost everything else follow, so get it early. A commit is a snapshot of the whole project, not a list of changes.

The vocabulary

• Repository — the project together with its whole recorded history.
• Commit — one recorded snapshot of every file at a moment.
• Staging area — the set of changes selected to go into the next commit.
• Diff — the difference between two snapshots, computed rather than stored.
• History — the sequence of commits, each with a message, a time and an author.
• Restore — bringing a file back to a state you recorded.

The mental model

Recording a commit stores the state of every file at that moment. The differences you look at are *computed* between snapshots, not kept. Once that lands, moving around history stops feeling dangerous. Nothing you are looking at is reconstructed from a chain of edits that might go wrong.

Before recording, you choose what goes in. That is the staging area, and it is the step most people skip. It is also the step that turns one messy afternoon into three commits that each do one thing. A history like that can be read, searched and undone piece by piece. A history of one enormous commit cannot.

Then the message. The code already shows *what* changed, so the message is for *why*. A year later the why is the only part nobody can reconstruct. A history of messages saying "update" is a history nobody can use. It was written by someone who had the information and did not spend ten seconds.

The payoff arrives when something breaks. Being able to find the commit that introduced a behaviour turns a mysterious defect into a dated, attributed, reviewable event. You stop asking "why does it do this?" and start asking "what did this change intend?", which is a much easier question.

And undoing. Almost everything you recorded can be recovered. A small number of operations genuinely discard work. Those are worth knowing by name *before* you need them, not during the ten minutes when you do.

What you should now be able to explain or do

Put a project under version control and record a first commit. Say why a commit is a snapshot and what that means for moving through history. Use the staging area to split one afternoon into commits that each do one thing. Write a message that explains why rather than what. Find the commit that introduced a behaviour. Restore a file, and name the operations that genuinely discard work.

Check yourself