Git's DAG and Object Model

You save a file called essay.txt. Git doesn't store the file itself—it stores a snapshot of what's inside it. That snapshot gets hashed (run through a mathematical function that produces a unique fingerprint). Change even one letter in essay.txt, and the hash completely changes. This fingerprint is how Git knows something shifted. 📎

Now you commit that snapshot. Git creates a commit object, which is like a container holding three things: the snapshot hash, a message you wrote, and a pointer to the previous commit (its parent). That commit object also gets its own unique hash. Make another commit, and the new one points back to the old one. String ten commits together and you've built a chain where each link points backward—that chain is a directed acyclic graph, or DAG. Acyclic means it never loops back on itself.

Here's the power: because every commit's hash depends on its content and its parent's hash, you can't secretly edit an old commit without breaking the entire chain downstream. The fingerprint would change, and every commit after it would have the wrong parent pointer. Git catches it instantly.

GitBook and GitLab are tools that use Git, not Git itself. GitLab is a hosting platform (like GitHub) where you push commits and collaborate. GitBook is a platform for publishing documentation—it can pull from a Git repository, but it's focused on rendering readable books, not managing your code's history. Both rely on Git's DAG underneath, but they solve different problems.

This immutability is why Git never loses work. Every commit is locked in place by its hash.