What a commit is
A commit records staged changes into Git’s history. The official glossary describes it as saving the state of the project as a new snapshot in the history.
Along with the changes themselves, a commit stores the author, the timestamp, its link to the preceding commit, and a message. Being able to walk that history is what makes it possible to find which change introduced a problem.
Bigger than saving a file
Saving writes your current edits to a file. A commit gathers one logical change, possibly spanning several files, into a described entry in the history.
Aim for units whose purpose is clear later — “add search button to header”, “fix typo”. Oversized commits are hard to review and hard to undo.
Committing does not send anything to GitHub
A commit normally goes into your local repository only. Sharing it to a remote such as GitHub requires a separate push.
That is why you can commit without an internet connection, and why GitHub Desktop has separate Commit and Push origin buttons: recording and sending are different operations.
Writing a good message
Go beyond “update” or “fix” to something that says what changed, such as “include readings in glossary search”. Follow your team’s format if there is one.
Committing a secret can leave it in the history even after you remove it from the current files. Make reviewing the diff before committing a habit.
Each commit has an identifier derived from its contents, generally called the commit hash. The short alphanumeric strings you see in bug reports and change discussions point at a specific commit, and they are a precise way to tell a person or an AI which state you mean.
If you notice a mistake after committing, the safe fix depends on whether you have shared it. For history you have already pushed, prefer adding a new corrective commit over rewriting it.