Git Internals

Inspect objects and refs until commit, branch, and tag are locations in a graph rather than product-button names.

Objects are Git, not GitHub

Git Working Tree named three places: working tree, index, object database. This lesson opens the third place. Git Commit already wrote a commit object. Git Branch already treated a branch as a pointer. Internals makes those sentences checkable with git cat-file, git ls-tree, and git rev-parse.

# These are Git. None of them talks to GitHub.
git cat-file -t HEAD
git cat-file -p HEAD
git ls-tree HEAD
git hash-object note.txt
git rev-parse HEAD

Use a disposable local repository. A journal or feature-branch project folder is fine if you still control it. You do not need a GitHub remote. You do not need gh.

Four object types

commit  9c2e…     ← refs/heads/main and HEAD name this
  │
  ├─ parent  4a11…  (earlier commit, or none on a root)
  ├─ tree    7f08…  (the snapshot)
  ├─ author / committer / message
  │
  ▼
tree 7f08…
  note.txt     blob  e4d9…   "hello\n"
  copy.txt     blob  e4d9…   same content, same blob
  src/         tree  1a2b…

A filename lives on the tree entry. The blob does not know it.

Git Log walks commits. git show often prints a commit plus a patch against its parent. That patch is a convenience. The stored object does not contain a unified diff.

Name an object, then print it

HEAD is a revision. Git resolves it to a commit (when you are on a branch). git cat-file -t prints the type. git cat-file -p pretty-prints the content.

# Disposable local repository. GitHub is not required.
git switch main
git rev-parse HEAD
git cat-file -t HEAD
git cat-file -p HEAD

The first lines of a commit are tree and, except on a root commit, parent. Those values are object ids. Copy one and run git cat-file -t on it. You are no longer taking the vocabulary on trust.

git hash-object note.txt hashes the file the same way Git names a blob. If the path is already committed unchanged, that id matches the blob column of git ls-tree. hash-object without -w prints the id and writes nothing. Do not add -w in this lab; dangling blobs are noise, not a lesson.

Walk HEAD to a blob

# HEAD^{tree} is the root tree of that commit.
git rev-parse HEAD^{tree}
git ls-tree HEAD
git cat-file -t <blob-id-from-ls-tree>
git cat-file -p <blob-id-from-ls-tree>

# Same blob id without looking it up first:
git hash-object note.txt

Each line from git ls-tree HEAD is mode, type, object id, and name. A blob line is a file. A tree line is a directory; git ls-tree that id to go one level down. git ls-tree -r HEAD flattens the walk. Learn the one-level listing first so you can see a nested tree as an object, not a path trick.

echo 'hello' > note.txt
git add note.txt
git commit -m "Add note"

echo 'hello' > copy.txt
git add copy.txt
git commit -m "Add a copy of the same bytes"

git ls-tree HEAD
# note.txt and copy.txt should list the same blob id.
git hash-object note.txt
git hash-object copy.txt

Identical bytes share a blob. Different bytes create a new blob. A later commit that only changes a message still points at a tree; if the tree did not change, Git reuses that tree object too. That is why two snapshots can be cheap without copying the project.

Refs are names, not copies

# HEAD is usually a pointer to a branch name, not a commit id.
git symbolic-ref HEAD
# prints refs/heads/main

git rev-parse HEAD
git rev-parse refs/heads/main

# On a typical new repo these two files match that SHA:
# .git/HEAD              →  ref: refs/heads/main
# .git/refs/heads/main   →  9c2e…

git rev-parse HEAD and git rev-parse refs/heads/main print the same SHA while you are on main. git symbolic-ref HEAD prints the branch name HEAD currently follows. That is the attached state Git Branch taught. Detached HEAD means .git/HEAD stores a commit SHA directly instead of ref: refs/heads/….

Read those files if you want the disk picture. Change refs with git switch, git branch, and git tag—not with a text editor. A truncated SHA in a ref file is a broken repository, not a shortcut.

Reachable is not the same as exists

An object can sit in the database without any branch, tag, or HEAD naming it. Commands that walk history start from refs. That is why git log can miss a commit you still git cat-file -p if you still know the SHA.

Git Recovery teaches reflog and how to get a durable name back on a commit. This lesson only needs the distinction: deleting a branch does not immediately delete objects. Running git gc may eventually prune unreachable ones. Do not prune as homework. Do not delete files under .git/objects to make the folder look tidy.

What not to invent

Guided practice: open one commit

1. 01
   Pick a local repository you own

   Clean status. On a branch. git rev-parse HEAD prints a SHA.

2. 02
   Print the commit

   git cat-file -t HEAD is commit. git cat-file -p HEAD shows tree, parent, message.

3. 03
   List the tree

   git ls-tree HEAD. Copy one blob id. git cat-file -p that id. Confirm it matches the working file if that path is unchanged.

4. 04
   Prove a ref

   git symbolic-ref HEAD and git rev-parse refs/heads/$(git branch --show-current) match git rev-parse HEAD.

5. 05
   Optional reuse

   Commit a second path with the same bytes. git ls-tree HEAD shows one blob id twice.

Independent lab: prove the graph

1. In a disposable local repository you own, record two commits. The second commit adds a second path whose content matches an existing file so two tree entries share one blob.
2. Show git cat-file -t HEAD as commit and git cat-file -p HEAD with a tree line and a parent line. Copy the tree id. Show git ls-tree HEAD with two names and the same blob id. Show git hash-object on either file matching that blob.
3. Show git symbolic-ref HEAD and the SHA from git rev-parse HEAD. If you read .git/HEAD and the branch file under .git/refs/heads/, they must agree with those commands. Do not edit them.
4. Write six lines: commit id, tree id, shared blob id, current branch ref (for example refs/heads/main), one sentence that distinguishes an object from a ref, and one sentence that says why you did not edit .git/objects.
5. Do not push. Do not open GitHub. Do not run git gc --prune=now. Keep this object walk separate from the published Git Recovery investigation.

Common internals mistakes

Lesson review

You can inspect Git objects and refs until commit, branch, and tag are locations in a graph rather than product-button names. Git Recovery uses that model to preserve displaced commits and isolate regressions. GitHub Security binds a signing key to exact commit bytes. The team CI project stays planned.

• I can git cat-file -t HEAD and git cat-file -p HEAD and read tree, parent, and message.
• I can git ls-tree HEAD, open a blob, and explain why two names can share one blob id.
• I can name the current branch ref and show it points at the same SHA as HEAD.
• I inspect with Git commands and leave .git/objects unedited.