git(1)
======

NAME
----
git - the stupid content tracker


SYNOPSIS
--------
[verse]
'git' [-v | --version] [-h | --help] [-C <path>] [-c <name>=<value>]
    [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
    [-p | --paginate | -P | --no-pager] [--no-replace-objects] [--no-lazy-fetch]
    [--no-optional-locks] [--no-advice] [--bare] [--git-dir=<path>]
    [--work-tree=<path>] [--namespace=<name>] [--config-env=<name>=<envvar>]
    <command> [<args>]

DESCRIPTION
-----------
Git is a fast, scalable, distributed revision control system with an
unusually rich command set that provides both high-level operations
and full access to internals.

See linkgit:gittutorial[7] to get started, then see
linkgit:giteveryday[7] for a useful minimum set of
commands.  The link:user-manual.html[Git User's Manual] has a more
in-depth introduction.

After you mastered the basic concepts, you can come back to this
page to learn what commands Git offers.  You can learn more about
individual Git commands with "git help command".  linkgit:gitcli[7]
manual page gives you an overview of the command-line command syntax.

A formatted and hyperlinked copy of the latest Git documentation
can be viewed at https://git.github.io/htmldocs/git.html
or https://git-scm.com/docs.


OPTIONS
-------
-v::
--version::
	Prints the Git suite version that the 'git' program came from.
+
This option is internally converted to `git version ...` and accepts
the same options as the linkgit:git-version[1] command. If `--help` is
also given, it takes precedence over `--version`.

-h::
--help::
	Prints the synopsis and a list of the most commonly used
	commands. If the option `--all` or `-a` is given then all
	available commands are printed. If a Git command is named this
	option will bring up the manual page for that command.
+
Other options are available to control how the manual page is
displayed. See linkgit:git-help[1] for more information,
because `git --help ...` is converted internally into `git
help ...`.

-C <path>::
	Run as if git was started in '<path>' instead of the current working
	directory.  When multiple `-C` options are given, each subsequent
	non-absolute `-C <path>` is interpreted relative to the preceding `-C
	<path>`.  If '<path>' is present but empty, e.g. `-C ""`, then the
	current working directory is left unchanged.
+
This option affects options that expect path name like `--git-dir` and
`--work-tree` in that their interpretations of the path names would be
made relative to the working directory caused by the `-C` option. For
example the following invocations are equivalent:

    git --git-dir=a.git --work-tree=b -C c status
    git --git-dir=c/a.git --work-tree=c/b status

-c <name>=<value>::
	Pass a configuration parameter to the command. The value
	given will override values from configuration files.
	The <name> is expected in the same format as listed by
	'git config' (subkeys separated by dots).
+
Note that omitting the `=` in `git -c foo.bar ...` is allowed and sets
`foo.bar` to the boolean true value (just like `[foo]bar` would in a
config file). Including the equals but with an empty value (like `git -c
foo.bar= ...`) sets `foo.bar` to the empty string which `git config
--type=bool` will convert to `false`.

--config-env=<name>=<envvar>::
	Like `-c <name>=<value>`, give configuration variable
	'<name>' a value, where <envvar> is the name of an
	environment variable from which to retrieve the value. Unlike
	`-c` there is no shortcut for directly setting the value to an
	empty string, instead the environment variable itself must be
	set to the empty string.  It is an error if the `<envvar>` does not exist
	in the environment. `<envvar>` may not contain an equals sign
	to avoid ambiguity with `<name>` containing one.
+
This is useful for cases where you want to pass transitory
configuration options to git, but are doing so on operating systems
where other processes might be able to read your command line
(e.g. `/proc/self/cmdline`),