commit

A commit is a single recorded change to a site’s code, saved permanently in the site’s history along with a short message describing what it does. Fix the phone number in the footer, and that is one commit. Add a new service page, and that is another. Each one is a distinct, described snapshot, and together they form the entire history of how the site came to be exactly what it is today.

This is the basic building block of version control. Nothing about a commit is fragile or temporary. Once it is made, it stays in the record permanently, which means any change can be traced back to exactly when it happened and, from the message attached to it, why.

Why it matters to you

Ownership of a website is, in a real sense, ownership of its commit history. A site where you own the code from the first commit means the entire build, every decision, every fix, every new page added since day one, lives in a repository under your account. If the relationship with whoever built it ever ended, you would not lose the site or its history. It is already yours, recorded from the start.

That history is also a practical safety net. If something breaks after a change, the commit history shows exactly what changed and when, which makes finding and undoing the problem a matter of minutes rather than guesswork.

How I use it

I make small, frequent commits rather than one enormous change bundled together, because a commit that does one clear thing is easy to review, easy to undo if it turns out wrong, and easy to explain months later when someone asks why a particular page looks the way it does. Each one gets a short, honest message describing the change, not a placeholder like “update” that tells a future reader nothing.

Commits are grouped into pull requests for review before they become part of the site’s main history, so nothing lands without a second look first. The repository holding all of this sits in your GitHub repository, under your account, from the very first commit onward.

What it looks like in practice

Look at a site’s commit history and you will see a list running back to the day the project started, each entry a short message and a date: “Add contact page,” “Fix broken link in footer,” “Update pricing copy.” Click into any one of them and you will see exactly which lines of which files changed, nothing more and nothing less than that one described step. It is, in effect, a diary of the site’s entire life, written automatically as the work happens.