Open a real `.git/objects/` store, tell a blob, tree, and commit apart by what each holds, and predict why two identical files collapse to one hash.

You saved the folder three times: `notes/`, `notes-backup/`, `notes-final/`, and felt every copy waste space. Git quietly keeps every version too, yet `.git/objects/` barely grows and never once records 'what changed' between them.

Read the one line inside a branch file and the ref: line inside `.git/HEAD`, then predict which single file a commit changes versus a switch, and why detached HEAD is a shape rather than a break.

You run `git switch dev` and every file in your project changes at once, yet not a single saved commit has moved. Something tiny on disk got rewritten, and finding it explains why branching costs almost nothing.

Follow the hash each commit stores for the one before it to trace the whole graph, then slide a ref off a commit and watch the object survive on disk, reachable through the reflog until garbage collection's grace period lapses.

You made five commits building `config.json`, then one `git reset` seemed to delete the last one. Nothing was erased: every commit still sits on disk, and finding the pointer that orders them explains exactly where it went.

Track one file across the working tree, `.git/index`, and your last commit, decode the two columns of `git status`, stage a single hunk with `git add -p`, and know what `.gitignore` can and cannot untrack.

Edit `config.json`, run `git add`, then change one line again, and your next commit keeps the earlier version, not what sits on disk. Three copies of one file exist at once, and one command chose between them.

Reconstruct every `git log`, `git diff`, `git blame`, and `git grep` result by hand as a walk over the commit snapshots, and see why re-reading history never adds a byte to `.git/`.

You scroll `git log` and picture git reading a stored list of what happened, but nothing is stored. Each line was recomputed a breath ago by walking your commits, and recomputed again the next time you look.

Pin a release to one commit with a tag that never moves, choose lightweight or annotated by the metadata it stores, read what each writes to `.git/refs/tags/` and `.git/objects/`, decode the `git describe` string, and number releases with semantic versioning.

You shipped `app.py` at the commit everyone now runs, then kept committing on top. Weeks later you need that exact snapshot back, and one small file, written once and never rewritten, still points straight at it.

Stash edits into the two-parent commit git writes under `.git/refs/stash`, restore them with apply (keeps the entry) or pop (erases it), and open a second `git worktree` that shares one object store while keeping its own HEAD and index.

You're mid-edit in `app.py` when a teammate pings: their fix needs the working tree clean right now. You don't want a half-baked commit, and you don't want to lose the last hour of work.

Write one 41-byte file to branch with nothing copied, watch a switch rewrite every working file to another snapshot while your commits hold still, drive two branches into divergence, and see why `-d` refuses before it strands a commit.

You run `git branch dark-mode` and a second 41-byte file lands next to the first, holding the identical 40-character hash. Your whole project, every file, was left exactly where it sat, and it finished instantly.

Drive two branches to divergence and watch one reachability check pick the write: a reachable tip fast-forwards a 41-byte ref with no new commit, a diverged tip builds a merge commit with two `parent` lines, and standing on the other branch swaps which is first parent.

`git merge feature` sometimes writes a brand-new commit and sometimes writes nothing at all, just nudges a pointer. Same command, same two branches, two different results on disk, and one check decides which.

Halt a merge on one overlapping line, read the disagreement as marker blocks, three index stages, and a MERGE_HEAD flag, flip between merge, diff3, and zdiff3 rendering, then stage the fix into a two-parent commit or abort clean.

`git merge feature` prints a conflict and stops. Two teammates changed the same line of `config.json`, and git refuses to guess which one wins, so it hands the disagreement back, written out in plain text on disk.

Correct the tip of your branch with `git commit --amend`, which writes a new commit and moves the ref while the original waits in the reflog, then queue a fix for a buried commit by writing a `fixup!` marker to fold in later.

You just committed `Add config.json`, then spot a typo in the message and reach to fix it in place. Git has no such button: change one byte and `git cat-file -p` prints a different object with a different name.

Rebuild your branch's commits onto a new base, watching each become a new object with the same diff but a fresh parent and hash, fold a queued `fixup!` marker into its target with `--autosquash`, and see why `ours` and `theirs` swap when a replay hits a conflict.

Your feature branch holds three commits, and `main` has moved ahead since you branched off it. You want your three sitting on top of today's `main`, carrying the same file changes on fresh footing.

Rewind a branch with `git reset` and pick with `--soft`, `--mixed`, or `--hard` how far the staging area and working tree follow; append a push-safe inverse commit with `git revert` (choosing a mainline with `-m` on a merge); and wipe untracked files with `git clean -fd`, the only one of the three the reflog cannot undo.

You ran `git reset` once and lost an afternoon of edits, then ran almost the same command another day and nothing bad happened at all. Undo in git is really three separate tools wearing one word.

Copy the change from any commit onto your current branch as a new object with its own hash while the original stays put, select a merge's mainline with `-m`, and run a range through the sequencer that halts on a conflict with four ways out.

A one-line fix lands on `main` as commit `a1b2c3d`, but the same bug is still live on `release/v2.5`. Merging the whole branch drags along ten unrelated commits; you want that single change and nothing else.

Pinpoint the commit that broke a test by halving a 1024-commit range in about ten classifications, read the `.git/BISECT_*` state the search parks on disk without moving your branch, and automate the whole loop with `git bisect run` (exit 0 good, 125 skip, non-zero bad).

A test passed at tag `v1.0` and fails on the newest commit, 1024 commits later. Testing them one at a time means 1024 runs; there is a way to name the culprit in ten.

Watch `git remote add` write two lines to `.git/config` with no network call, see `git fetch` fill `.git/objects/` and `refs/remotes/origin/` while your branches stay put, and read a `non-fast-forward` push rejection as the remote refusing to drop a teammate's commit.

You clone a coworker's repo, add their URL, and expect a live wire to their machine. Open `.git/config` instead: two text lines got written, and no connection was ever opened.

Search the server's `.git/` after opening a PR and find no new object, push more commits to see the diff re-resolve off the live tip with no update step, then run merge, squash, and rebase to land `refs/heads/main` at three different hashes.

You've clicked the green Merge button and watched your branch fold into `main`. Now grep the whole `.git/` folder for that button, the object store, the refs, the config, every command git ships, and it isn't there.

Place a file named `pre-commit` in `.git/hooks/`, `chmod +x` it, and watch git fork it on the next commit and abort on a non-zero exit, then clone the repo to find the hook gone and see why `--no-verify` skips your copy but never the server's `pre-receive`.

You run `git commit` and it just works, every time. Then one day it stops, refuses, and prints a line you wrote yourself, because a plain script sitting in `.git/hooks/` returned a number git did not like.

Read a team's model off its `git branch -a`, route one feature through trunk-based, GitFlow, and forking so identical code lands on `main` three ways, then pick the shape by release cadence and contributor trust.

Two teams, two printouts of `git branch -a`: one is a single line, the other a dozen. Same git binary, the same objects underneath, so the difference is a shape each team chose, not a feature git turned on.