wunder beta

🌿 Git & Version Control

Track and manage changes to any project like a developer. You'll understand commits, branches, and merges and be able to collaborate without overwriting each other's work.

8
lessons
~45 min
to learn
🔬 Science
subject
Adults
level
Start the course →

What you’ll learn

  1. Why Git Feels HardDiagnose why Git feels hard, and meet the three-sentence data model the rest of the course earns.Naming files report_final_REAL.docx is real version control — just a bad one, and every failure it has is something Git fixes. Git feels hard because it's taught as a recipe list, which is a substitute for the model and fails when the stakes are highest. The model is small: commits are snapshots with parents, branches are pointers, and every command moves pointers around that graph.
  2. The Three Places Your Work LivesDistinguish the working tree, staging area and repository, and justify why the middle one exists.Your work lives in three places at once, and the same file can be in three states simultaneously — which is why Git confuses people who expect Dropbox. The staging area exists so you can compose a commit rather than dump one, turning history into statements instead of sediment. git status is Git telling you where your work currently sits.
  3. A Commit Is a Snapshot, Not a DiffExplain commits as content-hashed snapshots and derive why history cannot be quietly edited.A commit is a complete snapshot, not a diff; Git computes diffs on demand, which is why checking out ancient commits is instant. Repos stay small because files are stored by content hash, so unchanged files are stored once. A commit's hash covers its parent's hash, so identity depends on the whole chain — you can replace history but never quietly edit it.
  4. Branches Are Just PointersUnderstand branches and HEAD as pointers, and see detached HEAD as an accurate report rather than an error.A branch is a 41-byte file holding one commit hash — nothing is ever copied. HEAD points at a branch, which points at a commit, which is why committing slides your branch along behind you. A detached HEAD simply means HEAD points at a commit directly: you're standing on a snapshot with no label in hand.
  5. Merging: Two Pointers, One AncestorExplain merging via the merge base, distinguish fast-forward from a merge commit, and read conflicts as questions.Git finds the merge base — the most recent common ancestor — and compares both tips against it, which is why it can auto-resolve most merges without guessing. If one branch is an ancestor of the other, it just slides the label (fast-forward); otherwise it creates a commit with two parents. Conflicts arise only when both sides changed the same lines, and Git asks rather than silently picking a winner.
  6. Rebase: Rewriting the StoryExplain what rebase really does to commits and derive the golden rule from hashing.Merging is honest but can produce unreadable history. Rebase replays your changes as brand-new commits on a new base: new parents, new hashes, with the originals left unreferenced but intact. Because colleagues hold the old hashes, rebasing shared commits gives them a divergent history — so rebase unpublished work freely and merge anything shared.
  7. Remotes: Someone Else's PointersExplain distribution, remote-tracking branches as stale bookmarks, and the fetch/pull/push trio.Git was written by Linus Torvalds in 2005 when the Linux kernel lost BitKeeper access, with 'fully distributed' among its stated goals: every clone holds the entire history. origin/main is not live — it records where the server's branch was when you last talked to it. fetch only updates bookmarks and is always safe; pull is fetch plus merge; push asks the server to move its label and refuses when that would orphan work.
  8. Undo: Why Almost Nothing Is LostUse the model to recover from mistakes, and choose correctly between revert, reset and restore.Destructive commands move labels; the snapshots are immutable and remain in the object database, and the reflog records every position HEAD held — so you lost the name of your work, not the work. Revert undoes forwards and is the safe choice for anything published; reset moves your branch label; --hard and restore are the genuinely dangerous ones because they overwrite uncommitted work Git never saw.

Questions this course answers

This course argues that Git feels hard mainly because:

The command list is a substitute for understanding, and it fails exactly when the stakes are highest. Underneath, Git's model is three sentences long — and once you can draw the graph, commands become derivable rather than memorized.

Why does the staging area exist at all?

Without it, an hour's work becomes one lump: 'fixed bug and some other stuff.' Staging lets you commit the bug fix alone, then the logging line separately — turning history into statements rather than sediment.

git status reports the same file as both staged and unstaged. What does that mean?

Staging copies the file's current state into your proposal. Edit it afterwards and the working tree moves on while the staged version stays put — two real, different versions, reported accurately.

Git stores each commit as:

Snapshots, not deltas — which is why checking out a five-year-old commit is instant. It stays small because files are stored by content hash: an unchanged file hashes the same, so Git stores nothing and points at the object it already has.

A commit's hash is computed from its contents, including its parent's hash. The most important consequence is:

Identity depends on the whole chain behind it. You can't modify a commit, only replace history with different commits that have different names — which is exactly what rebase does, and exactly why it carries a warning.

git branch feature returns instantly on a 10 GB repository because:

A branch is a name and a hash. Nothing is copied, ever. That's why branching is thoughtless in Git and was an afternoon's ordeal in the tools before it — and why the pull request could be invented at all.

Grounded in trusted sources

  • Scott Chacon & Ben Straub, Pro Git (2nd ed., Apress) — the official Git book, git-scm.com/book
  • git-scm.com — 'Getting Started: A Short History of Git' (BitKeeper breakdown, 2005; design goals of speed, simple design, non-linear development, fully distributed)
  • Git reference manual — git-add(1), git-commit(1), git-branch(1), git-switch(1), git-merge(1), git-merge-base(1), git-rebase(1), git-fetch(1), git-push(1), git-reflog(1), git-reset(1), git-revert(1), git-restore(1), git-gc(1)
  • Git documentation — gitrepository-layout(5) and Pro Git ch. 10 'Git Internals' (objects, trees, content addressing, packfiles)
  • GitHub Blog — 'Highlights from Git 2.23' (git switch and git restore introduced 16 August 2019 to split the overloaded git checkout)

Every Wunder lesson is built from real, reputable sources — never invented.

Related Science courses

🪟Glassmaking: Float Lines, Bottles, and Fiber📍GPS: How Satellites Tell You Where You Are🌾Grain Elevators: The Skyscrapers of the Prairie🏛️Grand Terminals: How Great Train Stations Work⚡Grid Operations: Frequency, Balance, and Blackouts🔌Grid-Scale Storage: Batteries, Pumped Hydro, and Beyond🩺Healthcare fundamentals for general knowledge🚛Heavy Diesel: The Engines That Haul

Wunder is a personalized learn-anything platform — tell it any topic and it builds a beautiful, fact-checked course in minutes, with narration, a knowledge check, and a college-style University track.

Browse more Science courses · All topics · Home

© 2026 Wunder Learning LLC · Terms & Privacy