What a Commit Actually Holds
You have made three commits without knowing exactly what one is. That is fine — you also drive without knowing the gearbox — but a small amount of detail here explains a lot of behaviour that otherwise looks arbitrary.
A commit holds four things: a snapshot of every tracked file, a link to the commit before it, who made it and when, and the message. Four things. Nothing else.
A snapshot, not a list of edits
Most people assume a commit stores "the changes" — the plus and minus lines from the diff. It does not. A commit records how the whole project looked at that moment, and Git works out the differences when you ask to see them.
That is why you can jump directly to any commit in the history without replaying everything since. The state is right there, complete.
The obvious worry — surely storing the whole project every time is enormous? — has a good answer, and it is genuinely clever, and it is out of scope for this book. Unchanged files are not duplicated. If you want the mechanism, that is the deep dive's first chapter.
The link to the previous commit
Each commit names the one that came before it, called its parent. That single link is what makes the history an ordered chain rather than a pile of unrelated snapshots.
It is also the reason branching in Chapter 6 costs almost nothing. If every commit already knows its own past, then a branch is just a note saying which commit is the latest — and creating one of those is instant.
Looking inside one
git show prints a commit's four parts and then its diff, so you can see all of it at once:
git show c8d1e07
Run it on Sandpiper's meeting-time commit and you get your name, the date, the message you wrote, and the one line that changed. Run it without a hash and Git shows the most recent commit.
Why commits cannot be edited
Here is the consequence that matters. The hash is generated from the commit's contents — the snapshot, the parent, the author, the date, the message. Change any of them and the hash changes too, which makes it a different commit.
So "editing a commit" is not a thing Git can do. What actually happens is that Git builds a replacement and moves on to it, leaving the original behind. That sounds like a technicality and it is the reason behind two things later: why --amend in the next chapter comes with a rule about when to use it, and why the reflog can still find the version you thought you had destroyed.
For now, one sentence is enough: a commit, once made, is fixed. Everything that looks like changing one is actually making a new one.
- "Git stores my changes as a list of edits." It stores snapshots and calculates the differences when you ask. Storing them efficiently is a real and interesting problem, and it is deliberately not this book's.
- "A snapshot of everything must make the repository enormous." Unchanged files are not duplicated between commits. The history of a text project is usually far smaller than people expect.
- "I can edit a commit message later with no consequence." You can change it, but the result is a new commit with a new hash. On your own machine that is harmless; once other people have the original, it is not, which is Chapter 4's rule.
- "The parent link is something I have to set." Git sets it automatically to whatever commit you were sitting on. You never type it, and you never need to.
- "Snapshot plus parent" is the whole model behind branches and merges in Chapter 6. Without it, a branch looks like a copy of your project and a merge looks like magic.
- Knowing a commit is fixed explains every warning in the next chapter in one sentence, instead of four separate rules to memorize.
- It also explains why committing often is cheap: a commit is a record, not a copy of everything you own.
Knowledge Check
What does a commit actually store about your project?
- A snapshot of every tracked file in the project as it was at that moment
- The list of added and removed lines since the previous commit was made
- Only the files you edited, with the rest fetched from the first commit
- A compressed copy of your entire folder, including files it was told to ignore
What is the parent link for?
- It puts the history in order, one commit pointing back at the previous one
- It records which developer's work the commit was originally based on
- It stores the files the commit did not change, to save space in the snapshot
- It links to the branch the commit belongs to, so branches can be reconstructed
Why can a commit never really be edited?
- Its hash comes from its contents, so any change produces a different commit
- Git marks commits read-only on disk, and the permission cannot be changed
- Because the commit has already been copied to a server that will not accept changes
- Because editing would break the diff, which is stored separately from the commit
Which part of a commit is the only one Git cannot produce for you?
- The message, because only you can know why the change was made at all
- The snapshot, because Git needs to be told which files belong in it
- The author, because Git cannot tell which person is at the keyboard
- The parent, because a commit has to be told where it belongs in the history
You got correct