On April 7, 2005 - four days after Linus Torvalds started writing it - Git made its first self-hosted commit. The message read simply: "Initial revision of 'git', the information manager from hell." Within weeks it was managing the source code for the Linux kernel, one of the largest collaborative software projects in history. The tool he built in a weekend is now used by over 100 million developers worldwide.
That origin story is not just a fun fact. It tells you something important about what Git is designed to do. Torvalds needed a system that could handle thousands of contributors simultaneously, work entirely offline, and make it nearly impossible to lose history. Every design decision Git made flows from those constraints. Understanding the philosophy is what separates people who memorize commands from people who actually understand what they're doing.
The Problem Git Was Solving
Before distributed version control, teams used centralized systems like CVS or Subversion. The model worked like a single filing cabinet in the office: everyone connects to the same server to check out files and push changes back. That sounds fine until the server goes down - and then nobody can work, nobody can see history, and if the hard drive fails with no backup, the entire project history disappears.
Git's answer was to stop treating the server as the source of truth. When you clone a Git repository, you do not just get the current files. You get the entire history - every commit, every version, every change ever recorded. Your laptop holds a complete copy of the project. If the server evaporates, any developer's machine can reconstruct it entirely.
Think of it less like a shared filing cabinet and more like every team member having their own complete copy of every document ever produced, synchronized periodically. That redundancy feels wasteful until the day someone accidentally deletes the server.
Snapshots, Not Differences
Here is where Git diverges from almost every other version control system that came before it, and where most explanations gloss over the interesting part.
Most older systems track changes as a list of differences. To reconstruct what a file looked like at version 10, they take the original file and replay all the edits in sequence - add this line, remove that one, change this word - until they arrive at version 10. It works, but it is slow for anything except the most recent version, and the mental model gets confusing fast.
Git does not do this. When you save your work in Git - when you make a commit - Git takes a photograph of every file in your project at that exact moment and stores a reference to that photograph. If a file has not changed since the last commit, Git does not bother photographing it again; it just points to the previous version. But conceptually, every commit is a complete picture of your project, not a list of differences from the previous picture.
Key Point: Every Git commit is a snapshot of your entire project at a specific moment in time. This is why you can jump to any point in your history instantly - Git is not replaying changes, it is loading a saved photograph.
This snapshot model is why Git operations feel fast even on large projects. Switching branches, comparing versions, viewing history - these are all just loading and comparing snapshots, not calculating chains of differences.
Data Integrity and the SHA-1 Hash
Every object Git stores - every file, every directory, every commit - gets a unique fingerprint calculated from its contents. Git calls this a SHA-1 hash: a 40-character string like 24b9da6552252987aa493b52f8696cd6d3b00373. That string is computed from the data itself. Change even a single character in a file and the hash changes completely.
This matters in a practical way you will notice immediately. You cannot reference a commit in Git with a name like "yesterday's version." You reference it by its hash - or the first several characters of its hash, which are usually enough to be unique. The hash is the address. The address is derived from the content. Content cannot be silently altered without Git detecting it.
The security implication is significant: no one can tamper with a commit without changing its hash, which would break every subsequent commit that references it. Git does not need to trust the network or the server. The data carries its own proof of integrity.
The Three Places Your Code Lives
At any moment, your code exists in one of three places in Git's model, and understanding where it is tells you exactly what has and has not been recorded.
The working directory is your regular file system - the files you open in your editor, the ones you are actively reading and modifying. Git can see these files and notice when they change, but it has not recorded anything about them yet. Think of this as your desk: things are in progress, nothing is filed.
The staging area (Git calls it the index) is the intermediate zone. When you decide you want to include a change in your next recorded snapshot, you move it here. The staging area is a holding pen for changes you have curated and approved, waiting to be committed. Think of it as the outbox on your desk: finished, ready to send, but not yet sent.
The repository is the permanent record - stored in a hidden .git directory in your project folder. When you commit, everything in the staging area gets packaged into a new snapshot and stored here permanently. Think of this as the archive: filed, timestamped, accessible forever.
Key Point: The three-area model - working directory, staging area, repository - gives you precise control over what gets recorded and when. You can make ten changes across five files and commit only the two that belong together, leaving the others for a later commit.
That control is what makes Git useful rather than just functional. You are not just saving files; you are building a readable history that explains what changed and why.