Check Git's Version and Build Details Safely

You will finish with a small, repeatable check for the Git release installed on a Linux machine, plus the build information useful in a bug report. The examples use Git 2.43.0 from Ubuntu package git 1:2.43.0-1ubuntu7.3 and its matching git-man package.

Allow about five minutes. You need a shell and the git command. No repository is required, no files are changed, and none of the commands need sudo. The output is host-specific, so compare the structure of the result rather than copying a version number into a script.

1. Confirm which Git command will run

Start with the shell's command lookup. This prevents a stale binary in a custom directory from being mistaken for the system Git:

$ command -v git
/usr/bin/git
$ git --version
git version 2.43.0

The first line is the executable path. The second is Git's normal version string. It contains the product name and release number, but not the Debian or Ubuntu package revision. If command -v returns a path you did not expect, inspect your PATH before reporting the result:

$ type -a git
git is /usr/bin/git

Checkpoint: record both the path and the version. If you are diagnosing a script, run these checks in the same shell and under the same account as the script.

2. Run the documented subcommand

Git also exposes the check as the version subcommand:

$ git version
git version 2.43.0

For this command, git --version and git version are equivalent. The top-level form is convenient when you are already checking command-line options; the subcommand is useful when you want the operation to read clearly in a diagnostic script. Do not add a repository path or run it from a particular working directory. Git reports its own executable version without inspecting repository contents.

Check the exit status immediately if another program depends on the result:

$ git version >/tmp/git-version.txt
$ status=$?
$ printf 'git version status: %s\n' "$status"
git version status: 0

The temporary file is optional. If you use it in a real script, choose a private, controlled location and remove it when it is no longer needed. The command itself only writes its version to standard output.

3. Collect build information for diagnostics

Use --build-options when a plain release number is not enough. It asks Git to include details about how the binary was built:

$ git version --build-options
git version 2.43.0
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh

On this installation, the output identifies the CPU architecture, whether a source commit is associated with the build, the sizes of two C types, and the shell path compiled into Git. These values can help separate a Git problem from a packaging or architecture difference. Exact fields vary between Git releases and builds, so do not parse a fixed line number unless you have a version-specific reason.

The option belongs after version. This is the documented shape:

$ git version --build-options > git-build-details.txt
$ test -s git-build-details.txt && echo 'build details captured'
build details captured

That redirection creates or replaces git-build-details.txt in the current directory. If the file already matters, use a new name or copy it first. There is no Git configuration change to undo, but ordinary shell redirection can overwrite a file before Git runs.

4. Keep package and executable versions separate

When you need a supportable system report, collect the package revision as a separate fact. Git itself prints 2.43.0; the package manager adds the distribution revision:

$ dpkg-query -W -f='${Package} ${Version}\n' git git-man
git 1:2.43.0-1ubuntu7.3
git-man 1:2.43.0-1ubuntu7.3

This command is specific to Debian-family systems. On another distribution, use that distribution's package query tool, but do not infer its package revision from git --version. The manpage installed here identifies its source as Git 2.43.0, which matches the executable; the package revision is additional distribution metadata.

Checkpoint: a useful report has the executable path, Git version, build-options output, operating-system release, and package revision where available. Keep the original command output rather than paraphrasing it.

5. Avoid common diagnostic traps

A version check does not prove that every Git feature works. It does not test repository permissions, remote access, credential helpers, hooks, or the configured identity. Move to those checks only after confirming which executable is in use.

Do not run the commands with sudo merely because another Git operation failed. Elevated execution can select a different PATH, configuration and home directory, which makes the diagnostic harder to compare with the failing command. Use elevated privileges only if your system administrator has a separate reason to inspect a protected installation or package database.

Do not treat the build output as a compatibility promise. A machine may have Git 2.43.0 built with different compiler options, libraries or patches from another machine. Include the complete output when asking for help, and state whether it came from git version or git --version.