Object Model and DAG

HEAD is a pointer to whatever you currently have checked out. Normally it is a symbolic ref holding the name of a branch, such as refs/heads/main, while the branch itself is a ref holding one commit hash.

In Git, HEAD~2 walks two steps back along the first-parent chain, i.e. the grandparent. HEAD^2 takes one step to the second parent, which exists only on a merge commit; on a non-merge it is an error.

In git log, main..feature lists commits reachable from feature but not from main. main...feature lists the symmetric difference: commits reachable from either side but not both. In git diff, three dots means something else — merge base against the right side.

A commit stores the hash of one tree (a full snapshot of the tracked files), the hashes of its parent commits, author and committer identity with timestamps, and the message. It stores no diff.

Git first writes each new object as its own zlib-compressed loose file under .git/objects. Packing rewrites many objects into a single .pack file that uses delta compression, plus an .idx index for lookup, cutting both disk usage and file count.

Git walks out from every ref, HEAD, the index and reflog entries, following commits to their parents, trees and blobs. Anything not reached is unreachable and eventually pruned, but only after a grace period based on object age.

Detached HEAD means HEAD holds a commit hash directly instead of naming a branch. Commits still work, but nothing points at them, so create a branch at that commit before switching away.

A bare repository has no working tree and no index: the contents normally found in .git sit directly in the repository directory, with core.bare set to true. Servers use them because nothing should be checked out there, and pushing to a checked-out branch is refused by default.

HEAD names the current branch, config holds repository-local settings, index is the staging area, objects/ is the object database, refs/ holds branches and tags, logs/ holds the reflogs, hooks/ holds hook scripts, and info/exclude holds unshared ignore patterns.

Git records files, not directories. A directory exists only as a tree object listing entries, and each entry must name a blob or a subtree, so a folder with nothing in it has nothing to record.

It prints the full object ID of the commit HEAD currently resolves to, one line on stdout. Scripts use it because it turns any revision expression into an unambiguous, stable identifier they can record or compare.

Your files stay exactly as they are on disk, but the folder stops being a Git repository: all history, branches, tags, stashes and configured remotes are gone, because .git is the entire repository and the working tree is only a checkout of it.

Run git rev-parse HEAD~3. It is Git's revision parser: it turns any gitrevisions expression — branch name, tag, abbreviation, caret/tilde suffix — into the full object ID, printing nothing else, which makes it the safe check before a destructive command.

Git names objects by a hash of their content, not by path, so identical bytes always produce the same blob id. The ten paths become ten tree entries that all point at one stored blob.

A lightweight tag is only a ref under refs/tags pointing straight at a commit. An annotated tag creates a real tag object holding a tagger, a date, a message and an optional signature, and the ref points at that object.

Write the content as a blob with git hash-object -w, put it in the index with git update-index, snapshot the index with git write-tree, wrap that tree with git commit-tree naming a parent, then point a branch at the result with git update-ref.

git cat-file -t prints an object's type, -s its size, and -p pretty-prints its contents according to that type. git cat-file -e tests existence through the exit code, and --batch modes stream many objects for scripts.

Porcelain commands are the human-facing UI — add, commit, log, merge — whose output is formatted for people and may change. Plumbing commands are low-level building blocks like cat-file, hash-object and rev-parse, with stable output meant for scripts.

A merge commit's first parent is the branch that received the merge. git log --first-parent follows only that edge, so it shows one entry per merge and hides the individual commits from merged branches — the integration history of the receiving branch.

The blob is still reachable from something you forgot: leftover backup refs, tags, remote-tracking refs, other worktrees, or the reflog. Until every path to it is gone and gc prunes past its grace period, the object stays on disk.

git ls-tree HEAD reads a committed tree object, while git ls-files --stage reads the index — so it shows staged additions and deletions HEAD lacks, plus a stage number per entry that exposes the three conflicting versions during a merge.

When .git is a file containing a gitdir: line — used by linked worktrees, submodules and git init --separate-git-dir — or when GIT_DIR and GIT_WORK_TREE, or the --git-dir and --work-tree options, point Git at a repository stored elsewhere.

Every object id becomes a 64-hex-character SHA-256 hash instead of a 40-character SHA-1, recorded in the repository config as an extension. The choice is repository-wide, fixed at creation, and cannot interoperate with SHA-1 repositories.

The commit-graph is a derived binary cache under .git/objects/info that stores each commit's parents, root tree and date plus generation numbers, so Git can answer history and reachability queries without decompressing commit objects from packs.

Because refs can be stored two ways. Git compacts loose one-file-per-ref storage into a single .git/packed-refs file, so a branch may exist only as a line there. Loose files, when present, take precedence.

Replace opportunistic gc --auto with scheduled maintenance: periodic incremental repacking, a multi-pack-index, a written commit-graph, reflog and prune windows chosen deliberately, and measurement via count-objects and verify-pack rather than guesswork.