Before touching architecture or internals, you need one clean mental picture of what Git is for. Everything else in this guide builds on it.

What it is: Git is a version control system — a program that tracks changes to files over time and lets you save “snapshots” of your project whenever you want. Each snapshot records exactly what every file looked like at that moment, who made the change, when, and why (through a short message you write).

Why it exists: Before tools like Git, developers either had no safety net at all (one shared folder, overwritten constantly) or relied on centralized systems where a single server held the “real” history and everyone had to be connected to it to do anything. Both approaches broke down as teams grew and projects got more complex. Git was created in 2005 by Linus Torvalds — the same person who created the Linux operating system kernel — because the tool the Linux project was using stopped being freely available, and nothing else on the market could handle thousands of contributors working on one codebase at the speed the Linux kernel needed.

Where it’s used: Git runs underneath almost every modern software project — from a solo developer’s hobby app to the codebases at Google, Amazon, Microsoft, and Meta, to open-source giants like the Linux kernel itself. Platforms like GitHub, GitLab, and Bitbucket did not invent version control — they are websites built on top of Git that add collaboration features like code review and issue tracking.

Practical example: Suppose you are building a shopping-cart feature for a website. You save your progress in Git every time you finish a small, logical piece of work — “added quantity selector,” “fixed price rounding bug.” If a change three days later breaks something, you do not have to guess what went wrong; you can look at the exact list of saved snapshots, see precisely what changed in each one, and pinpoint the exact snapshot that introduced the problem.

Git’s entire design rests on a small number of building blocks. Once you know these, the rest of the tool stops feeling mysterious.

Every project tracked by Git lives inside what is called a repository (often shortened to “repo”) — simply a folder that Git is watching. Inside that repository, your files pass through three distinct areas before a change is permanently recorded.

Git also introduces a handful of core objects and terms you will meet constantly:

graph LR
    A[Working Directory
your files on disk] -->|stage changes| B[Staging Area
changes ready to save]
    B -->|commit| C[Local Repository
full project history]
    C -->|push| D[Remote Repository
e.g. GitHub server]
    D -->|pull / fetch| C
    C -->|checkout| A
    

This three-plus-one structure is what gives Git its flexibility. Because every operation up to “push” happens entirely on your own machine, you can save snapshots, switch branches, and review history at any time — even with no internet connection at all.

This is the part most tutorials skip, but it explains almost every “why” question people have about Git later on.

Internally, Git does not store a list of line-by-line differences the way many people assume. Instead, every commit is a complete, compressed snapshot of your entire project at that moment, built from three types of objects:

Every one of these objects is identified by a unique 40-character fingerprint (a SHA-1 hash) calculated from its exact content. This is what people mean when they say Git is content-addressable: an object’s identity is a mathematical result of what is inside it. Change even a single character in a file, and its blob gets an entirely new fingerprint — Git never silently overwrites old data, it simply creates new objects and moves pointers around.

This is also why Git is astonishingly efficient with storage. If you change one file out of a thousand, Git does not duplicate the other 999 — the new commit’s tree simply reuses the exact same object references for anything that did not change, and only creates new objects for what did.

graph TD
    C1[Commit 1] --> T1[Tree]
    T1 --> B1[Blob: index.html]
    T1 --> B2[Blob: style.css]
    C2[Commit 2] --> T2[Tree]
    T2 --> B1
    T2 --> B3[Blob: style.css v2]
    C2 -->|parent pointer| C1
    

Production example: The Linux kernel repository contains well over a million commits and tens of thousands of files, yet a typical clone of the full history is a few gigabytes — not terabytes — precisely because of this reuse-by-reference design.

Here is the everyday rhythm a piece of work follows, from the moment you start typing to the moment it becomes part of the shared project.

Branching in practice: A branch is nothing more than a movable label pointing at a specific commit. When you create a new branch to build, say, a “dark-mode” feature, you are simply telling Git “start a new label here, and let new commits move that label forward, while leaving the original main label untouched.” This is why teams can have dozens of branches in progress at once, each representing a different feature or fix, without any of them interfering with one another until someone deliberately merges them.

Merging, conceptually: When two branches are combined, Git looks at the common ancestor commit both branches started from, then compares what changed in each branch since that point. If the two sets of changes touch different parts of the project, Git combines them automatically. If both branches changed the exact same lines, Git flags this as a merge conflict and asks a human to decide which version — or what combination of the two — should win.

Git belongs to a category called distributed version control systems, meaning every person’s local copy contains the entire project history, not just the latest snapshot. This single design decision shapes nearly all of Git’s strengths and weaknesses.

Trade-off in practice: Google’s main internal codebase is so enormous that a standard Git clone would be impractical, so Google built its own custom tooling around this exact limitation. Most companies, however, never approach that scale, and Git’s design remains the right trade-off for the overwhelming majority of projects — from a two-person startup to companies with several thousand engineers.

Git’s history is a permanent, shared record — which makes security both easier and harder than people expect.

Every commit is effectively a permanent log entry — which turns Git into one of the most detailed audit trails a team will ever have.

Because every commit records who made a change, when, and why (through its message), the accumulated history of a repository functions like a built-in activity log for the entire project. Teams routinely use this history to answer questions such as: Which change introduced this bug? Who last touched this file, and why? What did this function look like six months ago?

One particularly valuable safety net is the local reflog — a private record on your own machine of every place your branch pointer has been, including commits you thought you “lost” by accidentally undoing them. In most cases, work that seems to have vanished can be recovered from the reflog, because Git rarely deletes an object immediately; it simply stops pointing to it.

Production example: Large engineering organizations, including Amazon and Microsoft, tie commit history directly into their incident-review process — when something breaks in production, the first step is almost always tracing recent commits to the affected files to identify what changed and when.

Git itself is flexible enough to support very different team workflows — and just as easily supports bad ones.

Beyond software companies, Git is now used far outside traditional programming — data scientists version-control their analysis scripts, technical writers track documentation changes, and some legal and academic teams even use Git to manage collaborative long-form documents, taking advantage of the same reliable history and merging model.

Git succeeded where earlier tools struggled because it solved the core problem of collaborative software development directly: letting many people work independently, save their progress safely, and combine their work back together with confidence. Its distributed design — every clone holding the full history — turned out to be not just a technical curiosity but the reason it scales from a single hobbyist to the largest codebases on the planet.