Commits and Version History

You're three hours into editing a document when your coworker asks, "What did that paragraph say before you changed it?" You freeze. You don't know. You overwrote it. This is why commits exist.

A commit is a snapshot—a frozen photograph of every file in your project at one exact moment. When you commit, you're saying: "This is what my work looks like right now, and I want to remember it." Git stores that snapshot with a label and a message explaining what changed.

Here's how it works in practice. You create a file called recipe.txt and write "Add eggs to bowl." You run the commit command with a message: "Step 1 of cake recipe." Git photographs that state and stores it. Later, you add a new line: "Mix for 30 seconds." You commit again with the message "Step 2 of cake recipe." Now you have two snapshots, linked in order. You've built a chain of versions.

The magic part: you can jump back to any snapshot. If step 2 was a mistake, you can revert to step 1—your file looks exactly as it did then. You can also compare snapshots side by side and see exactly what changed between them.

This chain is your version history. It's a safety net and a time machine rolled into one. GitBook and GitLab both use Git under the hood, so they both preserve this history—but GitLab is a full platform for hosting and collaborating on Git repositories, while GitBook is a publishing tool that sits on top of Git for documentation. Either way, your commits are the foundation.