Git Advanced

At its core, Git is a content-addressable filesystem. Everything you store — file contents, directory layouts, commits and tags — lives in the object database under .git/objects as one of four object types: blob, tree, commit and tag.

Each object is identified by a hash computed from its content. Store the same bytes twice and you get the same object — Git deduplicates automatically. This is why most Git operations are fast and local: they are simple lookups by hash.

An object’s name is the hash of a header plus its content. Historically Git used SHA-1, producing 40-character hex object IDs. Newer repositories can use SHA-256, producing 64-character IDs, configured at git init --object-format=sha256.

Because the name is derived from content, an object’s ID changes the instant a single byte changes. This gives Git its integrity guarantee: if stored bytes were altered, the recomputed hash would no longer match.

A blob stores the raw contents of a file — nothing else. A blob has no filename, no permissions and no timestamp; those belong to the tree that references it. Two files with identical content, anywhere in the repo, share a single blob.

You can create a blob directly from text and inspect it with plumbing commands. This is the lowest level at which Git stores your data.

A tree represents one directory. Each entry records a mode (file type and permissions), a name, and the hash of either a blob (a file) or another tree (a subdirectory). Trees nest to form the full directory hierarchy of a snapshot.

Use git ls-tree to read a tree and see exactly which blobs and subtrees it points to.

A commit object ties together a single root tree (the full snapshot), zero or more parent commits, an author and committer with timestamps, and a message. A commit does not store diffs; it points to a complete tree, and diffs are computed on demand by comparing trees.

The first commit has no parent; a normal commit has one parent; a merge commit has two or more.

A lightweight tag is just a ref pointing at a commit. An annotated tag is a real object in the database: it stores the tagged object’s hash, a type, a tagger, a date, a message, and can be GPG-signed. Annotated tags are recommended for releases because they carry metadata and can be verified.

Two plumbing commands sit at the boundary of the object database. git hash-object computes an object’s ID and, with -w, writes it. git cat-file reads objects back: -t prints the type, -s the size, and -p pretty-prints the content.

Together they let you create and inspect any object by hand, which is the clearest way to understand the model.

Git’s commands split into two layers. Porcelain commands (add, commit, log, checkout) are the friendly user interface. Plumbing commands (hash-object, cat-file, write-tree, commit-tree, update-ref, rev-parse) are low-level tools intended for scripts and for building higher-level behaviour.

Porcelain output can change between versions; plumbing output is stable and machine-parseable, which is why scripts should prefer it.

You can assemble a commit using only plumbing. git write-tree turns the current index into a tree object and prints its hash. git commit-tree takes a tree (and optional -p parents and -m message) and produces a commit object. Finally git update-ref moves a branch to that commit.

This is exactly what git commit does for you under the hood.

A ref is a human-friendly name pointing at an object, usually a commit. Branches live under refs/heads/, remote-tracking branches under refs/remotes/, and tags under refs/tags/. A loose ref is simply a small file containing the target hash; refs can also be stored packed in .git/packed-refs.

Creating a branch is therefore extremely cheap — it writes one tiny file.

HEAD is a special ref that normally points indirectly at a branch, e.g. ref: refs/heads/main. This is a symbolic ref. When you commit, Git updates the branch HEAD names, and HEAD follows along.

A detached HEAD is when HEAD points directly at a commit rather than a branch. New commits then belong to no branch until you create one.

The reflog records where each ref (including HEAD) has pointed over time, locally on your machine. Every commit, checkout, reset, rebase and merge appends an entry. This is your primary recovery tool: even after a hard reset or a botched rebase, the old commit is still reachable through the reflog.

Reflog entries expire after a while (90 days by default for reachable entries), and they are not pushed to remotes.

Suppose git reset --hard HEAD~3 threw away three commits. Because the reflog still holds the old tip, you can find it with git reflog and restore it. Use git reset --hard <hash> to move the branch back, or git branch rescue <hash> to point a fresh branch at the lost work.

The lesson: with Git, a hard reset is rarely truly destructive — the commits linger until garbage collection.

The index, stored in .git/index, is a binary file listing the paths, modes and blob hashes that will form the next commit. It is the staging area: git add writes blob objects and records them in the index, and git commit turns the index into a tree.

You can read the index directly with git ls-files --stage, which shows each path’s mode, blob hash and stage number.

Newly written objects are stored loose: one zlib-compressed file each under .git/objects/ab/cdef.... Over time Git consolidates them into packfiles (.pack with a .idx), which store many objects together and use delta compression — similar objects stored as differences against a base. Packs are far smaller and faster to transfer.

git gc tidies the database: it packs loose objects, removes unreachable objects whose grace period has passed, prunes expired reflog entries, and packs refs. Objects still reachable from any ref or recent reflog entry are kept. Run git gc --aggressive occasionally for a more thorough repack, though it is slow.

Most commands trigger an automatic gc --auto when enough loose objects accumulate.

The commit-graph file (.git/objects/info/commit-graph) caches commit metadata — parents, generation numbers and commit dates — so that history walks (used by log, merge-base and reachability checks) avoid parsing every commit object. On large repositories this dramatically speeds up many operations.

On large working trees, git status spends most of its time scanning files for changes. The filesystem monitor (core.fsmonitor) hooks into OS file-change notifications so Git only re-examines files that actually changed, making status and other commands much faster.

Modern Git ships a built-in fsmonitor daemon you can enable with one config setting.

git filter-repo is the recommended tool for large-scale history rewriting: removing a file from all of history, stripping secrets, or splitting a repository. It walks the whole history and rewrites commits, which changes their hashes. Everyone who has a clone must re-clone or carefully reset, because the rewritten history is incompatible with the old one.

The older git filter-branch still exists but is discouraged: it is extremely slow, easy to misuse, and has dangerous default behaviours, so much so that Git now prints a warning recommending alternatives. git filter-repo is faster, safer and far more capable, and is the official replacement.

The BFG Repo-Cleaner is a fast, purpose-built tool for two common jobs: deleting large files from history and redacting secrets such as passwords. It is simpler but less general than filter-repo, and like any history rewrite it changes commit hashes. After cleaning, you typically run git reflog expire and git gc to physically remove the old objects.

git rebase -i opens a todo list of commits you can reorder, drop, reword or mark to edit. Reordering lines reorders commits; changing pick to reword lets you rewrite a message; edit stops at that commit so you can amend it. Because each commit is replayed, all rewritten commits get new hashes.

During an interactive rebase you can split a commit: mark it edit, run git reset HEAD^ to unstage its changes, then create two or more smaller commits. To join commits, use squash (combine and edit the message) or fixup (combine and discard the squashed commit’s message). These give you a clean, logical history before sharing.

When even the reflog cannot help — for instance after it was expired — git fsck --lost-found scans the object database and reports dangling commits and blobs that are no longer reachable from any ref. You can inspect a dangling commit and resurrect it by pointing a branch at its hash before garbage collection removes it.

Git’s default merge strategy is now ort (Ostensibly Recursive’s Twin), a faster reimplementation of the classic recursive three-way merge. The ours strategy records a merge but keeps only your side’s tree. Note the distinction from the -X ours / -X theirs options, which only decide conflicting hunks while still merging non-conflicting changes.

The octopus strategy merges more than two branches in a single commit, useful for batching topic branches that do not conflict. The subtree strategy is a variant of the recursive merge that adjusts the tree so one project can be merged as a subdirectory of another, which underpins the subtree workflow.

For files where a textual three-way merge is wrong — generated files, lockfiles, or binary formats — you can define a custom merge driver. A driver is a command configured in .git/config and assigned to paths via .gitattributes. The built-in union driver, for example, keeps lines from both sides instead of conflicting.

rerere (reuse recorded resolution) remembers how you resolved a conflict so that if the same conflict appears again — common during long-running rebases or repeated merges — Git replays your earlier resolution automatically. It records the pre-image of the conflict and the resolution you committed, storing them under .git/rr-cache.

git notes attach extra information to existing commits without changing them — the commit hash stays the same. Notes are stored in a separate ref (commonly refs/notes/commits) and shown by git log. They are handy for CI results, review links, or release annotations added after the fact.

Because notes live in their own ref, they must be fetched and pushed explicitly.

git replace creates a replacement ref under refs/replace/ that tells Git to substitute one object for another when reading history — without altering the originals. This modern, shareable mechanism supersedes the old .git/info/grafts file, which faked parent relationships locally. Replace refs are commonly used to stitch a shallow history onto an imported older one.

A submodule embeds another repository by recording a specific commit hash as a special gitlink entry in the tree; the nested repo stays separate and must be initialised and updated. A subtree merges another project’s history directly into a subdirectory of yours, so clones need no extra steps. Submodules keep histories cleanly separated; subtrees simplify consumption at the cost of a larger repository.

Sparse-checkout populates only a subset of the working tree, so huge monorepos check out just the paths you need while the full history stays in the repo. Partial clone (--filter=blob:none) goes further by omitting most object content at clone time and fetching blobs lazily on demand. Combined, they make working with enormous repositories practical.

git worktree lets one repository have multiple working trees checked out at once, each on a different branch, sharing the same object database. The main repo records linked worktrees under .git/worktrees/, and each linked tree has a .git file (not directory) pointing back. This avoids re-cloning just to work on two branches in parallel.

You can cryptographically sign commits and tags so others can verify authorship and integrity. Git supports GPG, SSH keys (gpg.format ssh), and gitsign (keyless signing via Sigstore). Signed objects are verified with git verify-commit or git log --show-signature. Signing protects against impersonation in the supply chain.

On the server, hooks enforce policy as pushes arrive. The pre-receive hook runs once per push and can reject the whole push by exiting non-zero. The update hook runs once per ref being updated, allowing per-branch rules (such as protecting main). The post-receive hook runs after acceptance for notifications or deployments. These hooks are central to access control and CI triggers.

git bisect performs a binary search through history to find the commit that introduced a bug. Mark a known good and bad commit, then automate the whole search with git bisect run <script>: Git checks out a midpoint, runs your script, and uses its exit code (0 = good, non-zero = bad) to narrow down to the culprit, with no manual steps.

A bundle packs commits, trees, blobs and refs into a single file you can move over any medium — email, USB, an air-gapped network — without a live server. The recipient can git clone or git fetch directly from the bundle file. Bundles can be full or incremental (a range of revisions), making them ideal for sneakernet syncs and backups.

git maintenance schedules routine upkeep so repositories stay fast without manual gc. Enabling it registers background tasks — incremental repacking, commit-graph writes, prefetching from remotes, and loose-object cleanup — that run on a timer. It is the modern, finer-grained replacement for relying solely on automatic garbage collection.