Git Internals: What a Commit Actually Is
Not a Diff. A Snapshot.
A common misconception: a git commit stores the CHANGES you made, like a diff. It doesn't - a commit stores a full snapshot of every file in the repository at that moment, plus a pointer to the parent commit before it. Git is smart enough to store the underlying file content efficiently (unchanged files are shared, not duplicated), but conceptually, every commit is a complete picture, not a delta.
commit a1b2c3d
tree: (snapshot of every file/folder at this point)
parent: f9e8d7c (the commit before this one)
author: ...
message: "Fix login redirect"This is exactly why rebasing works the way it does: `git rebase` takes a sequence of commits and replays them - snapshot by snapshot - on top of a different starting point, generating brand-new commits with new IDs along the way. It's not moving your changes; it's recreating them elsewhere, which is also why rebased commits have different hashes than the originals, even though the content looks identical.
This also explains why `git reset --hard` is genuinely destructive and `git revert` isn't: reset moves your branch pointer to point at a different snapshot and discards what's not reachable from it anymore; revert creates a NEW commit that's the inverse of an old one, leaving history intact. Understanding "commits are snapshots, branches are just pointers to a commit" resolves most of git's supposedly confusing behavior.