Definition
A commit in Git (a version control tool for code) permanently records the changes you made and keeps them as a single "snapshot" (a photo of one moment in time). It's saved with a note about who changed what, when, and why, so you can return to this point whenever you need to.
A save point you can return to anytime
You've probably had that sinking feeling when you accidentally deleted something important in a document, or your computer shut down before you saved. So we end up copying files again and again with names like 'final.docx', 'final_REAL.docx', and 'final_last_edit_v2.docx'. But once you have dozens of files, it's hard to tell what changed and where.
A commit does away with all that copying. It captures a specific moment of your work, like a landing spot for a time machine. It saves a snapshot of the state of all your files and records what you changed at the same time.
Once you've stacked up commits this way, you don't need to fear broken code or errors. That's because you can cleanly go back to a specific commit from the past, when everything worked well.
Gathering in front of the camera before the photo
When you commit, your changes aren't recorded the moment you edit a file. First, you go through a step called 'staging' (getting ready), where you pick which of your changed files go into this save.
It's like a group photo where only the people who belong in this shot step up onto the stage, not everyone. It's also like putting items in a shopping cart and paying for them all at once. After you've lined up the files you want on the stage, the command that snaps the photo is the commit.
Just as you might write a date and a note on the back of a photo, every commit needs a commit message (a short description), such as 'Fix login error'. Thanks to this note, your teammates can see at a glance what changed without opening the code file by file.
A bit more precisely: it's not a full copy
If Git copied every file in full each time, wouldn't your hard drive fill up fast? To save space, Git uses a very clever approach.
Compared with the previous commit, it saves only the files that changed. Files that didn't change are stored as links pointing to data that's already saved. Even changed files are first stored whole in compressed form, and later Git may run a separate compression step that keeps only the differences between similar pieces of data. On the surface it looks like a perfect snapshot of the whole project, but underneath it uses the bare minimum of space.
Every commit also gets its own unique ID (a hash), so commits never get mixed up. Each commit also records the hash of the commit right before it, so they're linked like a chain, in order, one after another. If someone secretly altered an old commit, its hash would change, and you'd spot it right away.
Common misconceptions
When you make a commit, your code is immediately uploaded to the internet for everyone to see.
A commit you make with Git on your own computer is kept only on your machine (locally), like a personal save file. It isn't shared with anyone until you send it to a remote repository with a separate command called 'push'. The exception: if you commit directly on a website like GitHub, it's recorded in the remote repository right away.
Where you meet it
After finishing a new login feature, you save your changes with the commit message 'Add login feature'.
While editing code, your program breaks completely, so you roll the whole project back to the commit from yesterday when everything still worked.
In one sentence
A commit is a digital save point that safely stores your code changes along with a descriptive note.