Git Fundamentals
Learn Git from first principles. Understand not only which commands to type, but what Git is actually doing with your files, commits, branches, references, objects, working tree and staging area.
This is the first pillar of Modern Git Academy: a twelve-lesson curriculum that takes you from “what is version control” to reading a commit object out of the object database by hand. It is designed to be worked through in order, and every lesson stands on its own as a reference you can return to.
Start with Lesson 1 Jump to the learning pathWhy Git is worth understanding properly
Section titled “Why Git is worth understanding properly”Most people learn Git as a list of incantations. git add ., git commit -m, git push. That gets you
through the first month. It stops working the first time something unexpected happens — a detached
HEAD, a conflict you did not cause, a commit that appears to have vanished — because a list of commands
gives you nothing to reason with.
Git is unusually rewarding to learn properly, because the underlying model is genuinely small. There are four kinds of stored object. There are three places your files can be. There is one rule about how names point at things. Almost every Git command is a consequence of those three facts.
Once you can hold that model, Git’s behaviour becomes predictable. Error messages become informative rather than alarming. And the operations that intimidate people — rebasing, resetting, recovering lost work — turn out to be straightforward applications of the same small set of ideas.
That is what this pillar teaches.
What Git is
Section titled “What Git is”Git is a distributed version control system. It records the state of a set of files over time, and lets many people build on the same project without overwriting each other’s work.
Three properties define it:
It records snapshots. Each commit stores what every tracked file looked like at one moment — not a list of edits. This single design decision is why branching is cheap, why merging works the way it does, and why history is safe.
It is distributed. Every clone contains the project’s complete history. You can commit, branch, diff and read history with no network at all. A server is a convention teams agree on, not a technical requirement.
It is content-addressed. Every object is named by a hash of its own content. Identical content is stored once, objects are immutable, and history cannot be quietly rewritten — altering an old commit changes its ID and every descendant’s ID with it.
The three-state model
Section titled “The three-state model”Almost every question a beginner has about Git — why did that not get committed, why does git diff
show nothing, why can I not switch branches — resolves to understanding three places and the commands
that move content between them.
Three stacked areas. At the top, the working tree: the files on disk you edit. In the middle, the index or staging area: the exact content prepared for the next commit. At the bottom, the repository: the object database of committed snapshots inside the .git directory. The command git add moves content from the working tree to the index; git commit moves it from the index into the repository; checkout and switch move it back out from the repository to the working tree.
The working tree is your project directory: one version of each file, held in ordinary files so ordinary tools can edit them. It has no memory.
The index — also called the staging area — is a file holding a complete description of your next commit. It is why you can commit one coherent change out of a messy afternoon’s work.
The repository is the .git directory: the object database holding every committed snapshot, plus
the references that name entry points into it.
git status reports the differences between these three. Once you read its output as three comparisons
rather than three lists of files, it stops being noise.
The vocabulary you will build
Section titled “The vocabulary you will build”| Term | What it actually is |
|---|---|
| Repository | A project plus its complete history, stored in .git |
| Commit | An immutable snapshot of the whole project, plus author, message and parent |
| Object ID | A 40-character hash of an object’s own content — its fingerprint |
| Branch | A movable pointer to a commit. A file containing one object ID |
| HEAD | A reference naming where you are, normally pointing at a branch |
| Working tree | The checked-out files you edit |
| Index | The staged content that will become the next commit |
| Blob | A stored file’s content — no name, no path, just bytes |
| Tree | A directory listing naming blobs and other trees |
| Remote | Another copy of the repository, given a short name like origin |
| Merge | Combining two lines of work, producing a commit with two parents |
Every one of these gets a full treatment in the lessons below. If any of them currently feels like a vague metaphor, that is exactly what this pillar is for.
The Git Fundamentals learning path
Section titled “The Git Fundamentals learning path”Cluster 1 — Getting Started — is twelve lessons in a deliberate order. The first three build the model, the next three set up your environment, and the last six examine each part of Git’s architecture in depth.
- Lesson 1: 01. What Is Git?Git is a distributed version control system that records project history as snapshots. Learn what it does, why it exists, and how developers use it.
- Lesson 2: 02. Git vs GitHubGit is version control software you run locally. GitHub is a hosting platform built around it. Here is exactly where one ends and the other begins.
- Lesson 3: 03. How Git Actually WorksA complete walkthrough of Git's data model: the working tree, the index, the object database, refs, and what git add and git commit really do.
- Lesson 4: 04. Installing Git on UbuntuInstall Git on Ubuntu with apt, verify the version, and configure identity, default branch, editor and credentials across all three config scopes.
- Lesson 5: 05. Installing Git on WindowsInstall Git on Windows with winget or the official installer, then configure line endings, the credential manager, default branch and your editor.
- Lesson 6: 06. Installing Git on macOSInstall Git on macOS using Xcode Command Line Tools or Homebrew, understand which binary you are running, and configure identity and credentials.
- Lesson 7: 07. Your First Git RepositoryCreate a repository, stage a file, make commits, read the log and diff your changes — a full hands-on walkthrough that explains every command.
- Lesson 8: 08. Understanding the Working TreeThe working tree is the checkout you edit. Learn tracked, untracked, modified, deleted and ignored files, and how git status reads them.
- Lesson 9: 09. Understanding the Git IndexThe index is a real file that holds the next commit's exact content. Learn what it stores, why Git has one, and how partial staging works.
- Lesson 10: 10. Understanding HEADHEAD is a symbolic reference to your current branch. Learn how it moves, what detached HEAD means, and how HEAD~ and HEAD^ navigate history.
- Lesson 11: 11. Git Objects ExplainedGit stores everything as four object types in a content-addressable database. Explore blobs, trees, commits and tags with real plumbing commands.
- Lesson 12: 12. Git Repository StructureA guided tour of a real .git directory — HEAD, config, index, objects, refs, logs, hooks and packed-refs — and which of them are conditional.
How the sequence works
Section titled “How the sequence works”Lessons 1–3 build the model. What Git is, how it differs from GitHub, and how its data model actually works. Nothing here requires Git to be installed — the goal is to give you something to reason with before you start typing commands.
Lessons 4–6 set up your environment. One lesson per platform, each covering installation, identity configuration, default branch, editor and credential handling. Read the one that matches your machine and skip the others.
Lesson 7 is hands-on. A complete guided tutorial building a real repository from an empty directory through three commits, with every command explained and every output shown.
Lessons 8–12 go deep. One lesson each on the working tree, the index, HEAD, the object database and the on-disk repository structure. These are the reference material you will return to.
What you will be able to do
Section titled “What you will be able to do”By the end of Cluster 1 you will be able to:
- Explain what Git is doing when you run
add,commit,switchandrestore— not just what to type. - Read
git statusandgit diffoutput accurately, including the cases that surprise people. - Stage part of a file, so each commit records one coherent change.
- Recognise detached HEAD, understand why it happens, and recover work made in it.
- Navigate history with
HEAD~,HEAD^and the reflog. - Read a commit, tree and blob directly out of the object database.
- Explain what every significant file inside
.gitis for. - Diagnose problems from Git’s own error messages instead of searching for the exact wording.
How these lessons are written
Section titled “How these lessons are written”Every article in this pillar follows the same structure, because consistency makes reference material usable:
- A concise answer near the top, so a lesson works as a quick reference as well as a tutorial.
- Commands with context — what a command does, why it is being run here, and what output to expect.
- Original diagrams where a picture genuinely helps, always alongside a prose explanation rather than instead of one.
- Common mistakes, drawn from the errors that actually recur, with the reasoning behind each.
- A mental model section giving you a compact way to hold the concept.
- Try It Yourself exercises that ask you to predict Git’s behaviour before you observe it.
Commands are verified against a real Git installation rather than reproduced from memory, and the outputs shown are the actual outputs. Where a lesson covers something that can age — an installer, a package manager, a vendor interface — it is marked as version-sensitive and records what it was checked against.
Prerequisites
Section titled “Prerequisites”Very few:
- Comfort with a terminal. You should be able to change directory, list files and create a file. You do not need to be fluent.
- A machine you can install software on — for Lessons 4 onwards. Lessons 1–3 need nothing.
- No prior version control experience. If you have used Subversion or Perforce, the section on centralised versus distributed in Lesson 1 will be worth reading carefully, since some intuitions transfer and some actively mislead.
Common questions about learning Git
Section titled “Common questions about learning Git”How long does it take to learn Git? The daily loop — status, add, commit, push — takes about an hour. The model underneath, which is what makes the rest of Git make sense, takes a few focused sessions. This cluster is roughly six hours of reading plus whatever time you spend on the exercises, and it deliberately front-loads the model rather than the command list.
Do I need GitHub to learn Git? No, and it is better if you do not use one at first. Every lesson up to and including Lesson 12 works on a local repository with no account, no network and no remote. Separating the tool from the platform is the whole point of Lesson 2.
Is Git only useful for programmers? No. Git works well for any project made mostly of text files — infrastructure definitions, documentation, configuration, research notes, technical writing. It is a poor fit for large binary files, which neither diff nor compress usefully.
Do I need to learn the command line? For these lessons, yes. Graphical Git clients are genuinely useful, but they present an interpretation of Git’s state, and interpretations vary between tools. The command line shows you Git itself, which is what you need while building the model. Once you have it, use whichever interface you prefer.
What if I break something? Almost nothing in Git is unrecoverable once it has been committed. The
object database never edits, only adds, and the reflog records where your branches have been. The
genuinely destructive operations are the ones that touch uncommitted work — git restore and
git reset --hard — and every lesson here flags them explicitly where they appear.
Should I learn rebase before merge? Neither, yet. Both are operations on the commit graph, and
they are far easier once the graph itself is familiar. They belong to a later cluster.
Why this matters beyond writing code
Section titled “Why this matters beyond writing code”Git stopped being purely a developer tool some time ago. In current engineering practice the repository is frequently the control plane for an entire system.
Infrastructure is defined in code — Terraform configurations, Kubernetes manifests, Ansible playbooks — and stored in Git, so infrastructure changes get the same review, history and rollback story as application changes. Continuous integration systems watch repositories, so a push runs tests and a merge can trigger a deployment: the commit becomes the unit of delivery. In GitOps, a repository holds the declared desired state of a running system, and deploying means merging a commit while rolling back means reverting one.
All of that rests on the properties covered in this pillar: immutable content-addressed objects, a commit graph with verifiable ancestry, and cheap branching. Understanding them is not academic — it is what makes the tooling built on top of Git comprehensible.
Ready for the next step?
Section titled “Ready for the next step?”Modern Git Workflows
Section titled “Modern Git Workflows”Move beyond Git fundamentals and learn how branches, merges, rebases, worktrees, large-repository features, automation and secure configuration work in real engineering teams.
Pillar 2 covers four clusters — Branching, Merging, Rebasing and Modern Git Productivity — across 33 lessons. Where this pillar teaches what Git is doing, Pillar 2 teaches the decisions built on top of it: whether a branch should exist, how long it should live, whether history should be merged or rebased, and how to work efficiently in repositories of any size.
Continue to Modern Git WorkflowsWhere this pillar goes next
Section titled “Where this pillar goes next”Cluster 1 covers the foundation. The Git Fundamentals pillar is planned to grow with further clusters covering everyday commands, troubleshooting and recovery. Those are not published yet, and no placeholder pages exist for them — this Academy publishes lessons when they are complete.
The wider Academy will extend into GitHub engineering, GitHub Actions and CI/CD, Git security and DevSecOps, DevOps and GitOps workflows, and AI-assisted development. Git Fundamentals is the foundation all of those build on, which is why it was built first and built thoroughly.