In Git, what does git rev-parse HEAD print, and why do scripts rely on it?

## What the command is for Git lets you name a commit in many ways: a branch name, a tag, `HEAD`, an abbreviated hash, `HEAD~3`, `main@{yesterday}`. Every command that takes a revision must first reduce that expression to a concrete object ID. `git rev-parse` is that reduction, exposed as a standalone plumbing command. Give it an expression, get back the object ID it denotes. `git rev-parse HEAD` therefore does two hops. `HEAD` is normally a *symbolic* ref — a file containing `ref: refs/heads/main` — so Git follows it to the branch ref, reads the object ID stored there, and prints it. The output is one line: the full hexadecimal object ID, 40 characters in a SHA-1 repository and 64 in a SHA-256 one. No abbreviation, no colour, no decoration, because plumbing output is meant to be consumed by another program. If `HEAD` is detached, it contains an object ID directly rather than a `ref:` line, and rev-parse simply prints that. In a freshly initialised repository, `HEAD` points at a branch that has no commits yet — the unborn branch — and `git rev-parse HEAD` fails with a non-zero exit status, which is a case scripts must handle rather than assume away. ## Why scripts want it A branch name is a moving target: `main` means something different tomorrow. An object ID is permanent and globally identifies exactly one commit. So the pattern in any build or deployment script is to resolve once, early, and use the resolved ID everywhere afterwards — stamped into a version string, embedded in an image tag, written into a manifest, echoed into logs. That way every artifact from that run refers to the same commit even if someone pushes mid-build. The alternatives are all worse. Scraping `git log -1` parses human output that may change. Reading `.git/HEAD` directly ignores symbolic refs, packed refs, worktrees and alternate `GIT_DIR` layouts. rev-parse handles all of that and is a documented, stable interface. ## The modes worth knowing - `git rev-parse --short HEAD` — an abbreviated ID, long enough to be unambiguous in this repository. Good for display, poor for storage, because the required length grows as the repository does. - `git rev-parse --abbrev-ref HEAD` — the current branch's short name, or the literal string `HEAD` when detached. The standard way to ask "what branch am I on" from a script. - `git rev-parse --verify <rev>` — resolve strictly: exactly one object, or fail. Combined with `--quiet` it becomes a clean existence test driven by exit status rather than output. - `git rev-parse --git-dir` — the path to the repository directory, honouring `GIT_DIR` and the `.git` *file* used by linked worktrees and submodules, where `.git` is not a directory at all. - `git rev-parse --show-toplevel` — the absolute path of the working tree root, the reliable way for a script to anchor relative paths. - `git rev-parse --is-inside-work-tree` — prints `true` or `false`, so a script can bail out politely when run outside a repository. ## Exit codes and error handling Because it is plumbing, rev-parse communicates failure through its exit status, and that is the intended way to use it. Two idioms are worth memorising: `git rev-parse --verify --quiet <rev>` to test that a revision resolves, and `git rev-parse --is-inside-work-tree` to test that you are inside a repository at all. Any script that runs `git rev-parse HEAD` without checking the exit status will silently produce an empty or error-laden value in an empty repository or outside a working tree. ## Where the boundary is rev-parse is also the command that implements Git's full revision syntax, so it can resolve far more elaborate expressions than `HEAD`. For plumbing purposes what matters is the contract: one expression in, one unambiguous object ID or path out, on stdout, with the exit status carrying success. That contract is what makes it the first line of almost every Git-aware script.