Commit

Before version control tools became standard, the entire history of a project lived in copies of folders. A directory would fill up with project_0512, project_0512_fixed, and project_final sitting side by side, and the only place that recorded which copy was actually running was the memory of the person who made them.

That arrangement collapsed the moment something broke. If a checkout screen that worked last week stopped opening today, the only thing to query was a colleague. Someone would ask what had changed in between, hear "I touched the checkout code and the login code a bit," and then the two of them would sit down and compare yesterday's folder against today's line by line. Nothing anywhere recorded what changed, when, or for what reason, so finding a cause meant reconstructing a memory.

A commit moves that memory out of people's heads and into the project itself. It separates saving a file from the deliberate act of drawing a line and saying, "this much is one change, and here is the reason for it." Once the lines exist, somebody who joins two years later can read the history along them, and anyone can pick out a single line and erase just that one.

A commit does not appear when you save a file. You choose what goes into it and then create it by hand. There are three steps.

1. Edit the files. Nothing is recorded yet, and the edits exist only on your own machine.
2. Select which of those edits belong in this record. If you fixed a bug in the morning and swapped a font in the afternoon, you can include only the bug fix now and leave the font for the next record. The holding area where you gather what goes in is called staging.
3. Attach a message and finalize it. A message earns its keep by explaining why rather than what. "Fix code" ages badly; "fix share link expiry always computing as zero" is still useful a year later.

A finished record holds four things: the changed lines, the author and timestamp, the message, and a pointer to the commit that came directly before it. That last piece is what turns commits from loose items into a chain. Follow the chain backwards and it runs all the way to the day the repository was created, which is why you can land precisely on "the state it was in three Tuesdays ago."

Every record also carries its own identifier. It looks like a3f9c21, though the full value is forty characters and people quote only the first seven in conversation. The reason it isn't a counter going 1, 2, 3 is that several people create records on separate machines at the same time. Sequential numbers would collide.

Sizing a commit comes down to a single rule: one reason per record. Bundle a bug fix together with a font swap and there is no clean way to revert only the font later. Go to the other extreme and record every single edited line, and the history fills with noise nobody can read.

Commits accumulate on a branch, a line of work split off so you can build without disturbing the main one. You stack several commits there and then merge the whole set back. The request to merge it is a pull request, and the process where a teammate reads that request and leaves comments is code review. Reviewers often look at all the changed files at once, but when the commits are split by reason they can read them in order and replay how the work actually unfolded.

Commits are also the unit for tracing a cause. When something that worked yesterday fails today, you walk the records in between and narrow down which one introduced the break. With small commits the search collapses to a handful of lines; with three days of work in a single record you are reading four hundred lines to find it. Undoing just the offending record is a rollback, and that stays clean only when each commit held one reason.

Automated checks use commits as their trigger too. Running the test suite on every new record and reporting back whether it passed is continuous integration (CI), and the "every" in that sentence means every commit that lands.

"There's way too much in this one commit. Can you split it into two or three and push again?"

It's hard to review and impossible to revert in pieces, so the request is to slice it by reason.

"Step through the commits and you'll find where it broke."

Check the records between the last working state and the broken one, one at a time, until the culprit turns up.

"Please put the ticket number in the commit message."

Make it possible to trace this change back to whatever request started it.

At Pagedeck, Theo built document share links over three days. He recorded link creation, expiry handling, permission checks, and the error screen separately, which came to seven commits. The day after release, Mia passed along support tickets saying share links were expiring after a single day. Theo opened only the two commits that touched expiry and found the miscalculated line in ten minutes.

Had the same work gone up as one commit called "share link feature," the starting point would have been every file the work touched. Splitting commits costs effort on the day you write them and pays it back on the day something breaks.

The most common misreading is that committing makes your work visible to everyone. It feels like a save button, so the assumption is a fair one. But a commit lands only in the history on your own machine; sharing it takes a separate step that sends it to the remote copy. People who miss this commit a day of work, tell the team they've pushed it, and then wonder why nobody can pull the code. The split is deliberate rather than an inconvenience: it lets you record freely while an idea is still half-formed, tidy the records up afterwards, and only then show the team a history worth reading.

The other frequent mistake is treating a commit as something you do once, when the work is finished. The word "record" suggests preserving a result. In practice you record whenever a piece of the work becomes meaningful on its own. Save it all for the end and three days collapse into one lump, leaving no point to revert to and no earlier state to return to when an approach turns out wrong. A useful habit is to record whenever you could write one honest sentence about what you just finished.