Use git help to Find the Right Git Manual Quickly

You will finish with a small set of commands for discovering Git's command list, opening the exact manual you need, checking aliases, and choosing a text, Info, or web viewer. The examples match Git 2.43.0, installed here from Ubuntu package git-man 1:2.43.0-1ubuntu7.3. Check your own version first because a newer Git may add commands or documentation.

Allow about ten minutes. You need Git and a terminal. These commands are read-only: they do not need sudo, do not need a repository, and do not change files unless you deliberately save a Git configuration choice in a later step.

1. Confirm which Git you are using

Start with the version check:

$ git --version
git version 2.43.0

This matters when a colleague, script, or online answer refers to an option that is absent from an older installation. The git-help(1) manual shipped with your package is the reliable reference for the command actually on your machine.

2. Get the short command overview

Run git help with no topic:

$ GIT_PAGER=cat git help
usage: git [-v | --version] [-h | --help] [-C <path>] [-c <name>=<value>]
           [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
           ...

These are common Git commands used in various situations:

start a working area (see also: git help tutorial)
   clone     Clone a repository into a new directory
   init      Create an empty Git repository or reinitialize an existing one

The command prints the Git synopsis followed by commonly used commands grouped by purpose. The output can be longer than the terminal window. GIT_PAGER=cat makes this example finish directly instead of opening a pager, which is useful in scripts and copy-and-paste checks. For interactive reading, omit it and let Git use your normal pager.

3. Open one command's full manual

Pass a command name to read its detailed manual page:

$ git help status

With the default settings, Git asks the man program to display git-status(1). Press q to leave a typical man viewer. The same request can be written as:

$ git status --help

Git internally treats the second form as git help status. A common distraction is looking for a repository before asking for help. You can run this command from any directory. If you want plain output for a quick check, choose the man format and send the result to a file or another command:

$ GIT_PAGER=cat git help --man status | sed -n '1,24p'
GIT-STATUS(1)                     Git Manual                     GIT-STATUS(1)

NAME
       git-status - Show the working tree status

If the topic is a Git manual rather than a subcommand, use its documented name. For example, git help git opens the main Git manual and git help help opens this help manual.

4. List commands, guides, and configuration names

Use the listing options when you know the area but not the command:

$ git help --all
$ git help --guides
$ git help --config

--all lists available commands. It can also include external git-* programs found on your PATH and configured aliases. That is useful for discovery, but the result may include local additions that are not part of Git itself. For a narrower built-in command list, use:

$ git help --all --no-external-commands --no-aliases

--guides, or its short form -g, lists concept guides such as tutorial, everyday, and faq. --config, or -c, prints the names of available configuration variables. It is a catalogue, not a command to change configuration.

5. Inspect an alias instead of its manual

If you pass an alias name, Git prints the alias definition:

$ git help co
'co' is aliased to 'checkout'

To read the manual for the underlying command, use git help checkout, or ask for git checkout --help. This distinction prevents a frequent error: treating a local shortcut as if it were a standard Git command.

Alias expansion can run more than a simple command, depending on the configuration. Inspect an unfamiliar alias before executing it. If the alias invokes a shell command, treat it as executable configuration and review it with the same care as a script.

6. Choose a different documentation format

Git supports three output choices for a topic:

• --man or -m uses the man format.
• --info or -i uses the Info program.
• --web or -w opens the HTML manual in a browser.

For example:

$ git help --info log
$ git help --web diff

The web form may launch a browser or another helper. It can use help.browser, then web.browser, or a suitable default selected by Git's git web--browse helper. Do not use a web viewer in a restricted session unless you expect that external program to start.

You can set a default format, but this changes your user configuration. It is not required for one-off use:

$ git config --global help.format man

To undo that specific setting later, remove it from the global configuration:

$ git config --global --unset help.format

For a one-off choice, prefer the option on the command line. The manual also documents man.viewer, browser settings, and custom viewer commands. A custom man.<tool>.cmd is passed to a shell evaluation, so only use a value you understand and trust.

7. Handle the common failures

If a topic cannot be found, check its spelling and whether it is a command or a guide. git help tutorial asks for a guide, while git help clone asks for a command manual. Use git help --all or git help --guides to discover the exact names.

If Git reports that no man viewer is available, use --info, --web, or your system's manual-page package. This is a viewer problem, not evidence that the Git command is missing. If a browser opens the wrong page, inspect help.browser and web.browser before changing them, then test with an explicit --web invocation.

Most help commands need no elevated privilege. If a manual viewer has been configured to read a protected custom path, fix that viewer configuration rather than running the entire help command with sudo. Root can select a different global configuration and make the result misleading.