NAME

git - the stupid content tracker

SYNOPSIS

  1. git [--version] [--help] [-C <path>] [-c <name>=<value>]
  2.     [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
  3.     [-p|--paginate|-P|--no-pager] [--no-replace-objects] [--bare]
  4.     [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
  5.     [--super-prefix=<path>]
  6.     <command> [<args>]

DESCRIPTION

Git is a fast, scalable, distributed revision control system with anunusually rich command set that provides both high-level operationsand full access to internals.

See gittutorial[7] to get started, then seegiteveryday[7] for a useful minimum set ofcommands. The Git User’s Manual has a morein-depth introduction.

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

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

OPTIONS

  • —version

  • Prints the Git suite version that the git program came from.

  • —help

  • Prints the synopsis and a list of the most commonly usedcommands. If the option —all or -a is given then allavailable commands are printed. If a Git command is named thisoption will bring up the manual page for that command.

Other options are available to control how the manual page isdisplayed. See git-help[1] for more information,because git —help … is converted internally into githelp ….

  • -C
  • Run as if git was started in instead of the current workingdirectory. When multiple -C options are given, each subsequentnon-absolute -C <path> is interpreted relative to the preceding -C<path>. If is present but empty, e.g. -C "", then thecurrent 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 bemade relative to the working directory caused by the -C option. Forexample the following invocations are equivalent:

  1. git --git-dir=a.git --work-tree=b -C c status
  2. git --git-dir=c/a.git --work-tree=c/b status
  • -c =
  • Pass a configuration parameter to the command. The valuegiven will override values from configuration files.The is expected in the same format as listed bygit config (subkeys separated by dots).

Note that omitting the = in git -c foo.bar … is allowed and setsfoo.bar to the boolean true value (just like [foo]bar would in aconfig file). Including the equals but with an empty value (like git -cfoo.bar= …) sets foo.bar to the empty string which git config—type=bool will convert to false.

  • —exec-path[=]

  • Path to wherever your core Git programs are installed.This can also be controlled by setting the GITEXEC_PATHenvironment variable. If no path is given, _git will printthe current setting and then exit.

  • —html-path

  • Print the path, without trailing slash, where Git’s HTMLdocumentation is installed and exit.

  • —man-path

  • Print the manpath (see man(1)) for the man pages forthis version of Git and exit.

  • —info-path

  • Print the path where the Info files documenting thisversion of Git are installed and exit.

  • -p

  • —paginate

  • Pipe all output into less (or if set, $PAGER) if standardoutput is a terminal. This overrides the pager.<cmd>configuration options (see the "Configuration Mechanism" sectionbelow).

  • -P

  • —no-pager

  • Do not pipe Git output into a pager.

  • —git-dir=

  • Set the path to the repository. This can also be controlled bysetting the GIT_DIR environment variable. It can be an absolutepath or relative path to current working directory.

  • —work-tree=

  • Set the path to the working tree. It can be an absolute pathor a path relative to the current working directory.This can also be controlled by setting the GIT_WORK_TREEenvironment variable and the core.worktree configurationvariable (see core.worktree in git-config[1] for amore detailed discussion).

  • —namespace=

  • Set the Git namespace. See gitnamespaces[7] for moredetails. Equivalent to setting the GIT_NAMESPACE environmentvariable.

  • —super-prefix=

  • Currently for internal use only. Set a prefix which gives a path fromabove a repository down to its root. One use is to give submodulescontext about the superproject that invoked it.

  • —bare

  • Treat the repository as a bare repository. If GIT_DIRenvironment is not set, it is set to the current workingdirectory.

  • —no-replace-objects

  • Do not use replacement refs to replace Git objects. Seegit-replace[1] for more information.

  • —literal-pathspecs

  • Treat pathspecs literally (i.e. no globbing, no pathspec magic).This is equivalent to setting the GIT_LITERAL_PATHSPECS environmentvariable to 1.

  • —glob-pathspecs

  • Add "glob" magic to all pathspec. This is equivalent to settingthe GIT_GLOB_PATHSPECS environment variable to 1. Disablingglobbing on individual pathspecs can be done using pathspecmagic ":(literal)"

  • —noglob-pathspecs

  • Add "literal" magic to all pathspec. This is equivalent to settingthe GIT_NOGLOB_PATHSPECS environment variable to 1. Enablingglobbing on individual pathspecs can be done using pathspecmagic ":(glob)"

  • —icase-pathspecs

  • Add "icase" magic to all pathspec. This is equivalent to settingthe GIT_ICASE_PATHSPECS environment variable to 1.

  • —no-optional-locks

  • Do not perform optional operations that require locks. This isequivalent to setting the GIT_OPTIONAL_LOCKS to 0.

  • —list-cmds=group[,group…​]

  • List commands by group. This is an internal/experimentaloption and may change or be removed in the future. Supportedgroups are: builtins, parseopt (builtin commands that useparse-options), main (all commands in libexec directory),others (all other commands in $PATH that have git- prefix),list- (see categories in command-list.txt),nohelpers (exclude helper commands), alias and config(retrieve command list from config variable completion.commands)

GIT COMMANDS

We divide Git into high level ("porcelain") commands and low level("plumbing") commands.

High-level commands (porcelain)

We separate the porcelain commands into the main commands and someancillary user utilities.

Main porcelain commands

Ancillary Commands

Manipulators:

Interrogators:

Interacting with Others

These commands are to interact with foreign SCM and with otherpeople via patch over e-mail.

Reset, restore and revert

There are three commands with similar names: git reset,git restore and git revert.

  • git-revert[1] is about making a new commit that reverts thechanges made by other commits.

  • git-restore[1] is about restoring files in the working treefrom either the index or another commit. This command does notupdate your branch. The command can also be used to restore files inthe index from another commit.

  • git-reset[1] is about updating your branch, moving the tipin order to add or remove commits from the branch. This operationchanges the commit history.

git reset can also be used to restore the index, overlapping withgit restore.

Low-level commands (plumbing)

Although Git includes itsown porcelain layer, its low-level commands are sufficient to supportdevelopment of alternative porcelains. Developers of such porcelainsmight start by reading about git-update-index[1] andgit-read-tree[1].

The interface (input, output, set of options and the semantics)to these low-level commands are meant to be a lot more stablethan Porcelain level commands, because these commands areprimarily for scripted use. The interface to Porcelain commandson the other hand are subject to change in order to improve theend user experience.

The following description dividesthe low-level commands into commands that manipulate objects (inthe repository, index, and working tree), commands that interrogate andcompare objects, and commands that move objects and references betweenrepositories.

Manipulation commands

Interrogation commands

In general, the interrogate commands do not touch the files inthe working tree.

Synching repositories

The following are helper commands used by the above; end userstypically do not use them directly.

Internal helper commands

These are internal helper commands used by other commands; endusers typically do not use them directly.

Configuration Mechanism

Git uses a simple text format to store customizations that are perrepository and are per user. Such a configuration file may looklike this:

  1. #
  2. # A '#' or ';' character indicates a comment.
  3. #
  4.  
  5. ; core variables
  6. [core]
  7.     ; Don't trust file modes
  8.     filemode = false
  9.  
  10. ; user identity
  11. [user]
  12.     name = "Junio C Hamano"
  13.     email = "gitster@pobox.com"

Various commands read from the configuration file and adjusttheir operation accordingly. See git-config[1] for alist and more details about the configuration mechanism.

Identifier Terminology

  • Indicates the object name for any type of object.

  • Indicates a blob object name.

  • Indicates a tree object name.

  • Indicates a commit object name.

  • Indicates a tree, commit or tag object name. Acommand that takes a argument ultimately wants tooperate on a object but automatically dereferences and objects that point at a .

  • Indicates a commit or tag object name. Acommand that takes a argument ultimately wants tooperate on a object but automatically dereferences objects that point at a .

  • Indicates that an object type is required.Currently one of: blob, tree, commit, or tag.

  • Indicates a filename - almost always relative to theroot of the tree structure GIT_INDEX_FILE describes.

Symbolic Identifiers

Any Git command accepting any <object> can also use the followingsymbolic notation:

  • HEAD

  • indicates the head of the current branch.

  • a valid tag name(i.e. a refs/tags/<tag> reference).

  • a valid head name(i.e. a refs/heads/<head> reference).

For a more complete list of ways to spell object names, see"SPECIFYING REVISIONS" section in gitrevisions[7].

File/Directory Structure

Please see the gitrepository-layout[5] document.

Read githooks[5] for more details about each hook.

Higher level SCMs may provide and manage additional information in the$GIT_DIR.

Terminology

Please see gitglossary[7].

Environment Variables

Various Git commands use the following environment variables:

The Git Repository

These environment variables apply to all core Git commands. Nb: itis worth noting that they may be used/overridden by SCMS sitting aboveGit so take care if using a foreign front-end.

  • GIT_INDEX_FILE

  • This environment allows the specification of an alternateindex file. If not specified, the default of $GIT_DIR/indexis used.

  • GIT_INDEX_VERSION

  • This environment variable allows the specification of an indexversion for new repositories. It won’t affect existing indexfiles. By default index file version 2 or 3 is used. Seegit-update-index[1] for more information.

  • GIT_OBJECT_DIRECTORY

  • If the object storage directory is specified via thisenvironment variable then the sha1 directories are createdunderneath - otherwise the default $GIT_DIR/objectsdirectory is used.

  • GIT_ALTERNATE_OBJECT_DIRECTORIES

  • Due to the immutable nature of Git objects, old objects can bearchived into shared, read-only directories. This variablespecifies a ":" separated (on Windows ";" separated) listof Git object directories which can be used to search for Gitobjects. New objects will not be written to these directories.

Entries that begin with " (double-quote) will be interpretedas C-style quoted paths, removing leading and trailingdouble-quotes and respecting backslash escapes. E.g., the value"path-with-\"-and-:-in-it":vanilla-path has two paths:path-with-"-and-:-in-it and vanilla-path.

  • GIT_DIR

  • If the GIT_DIR environment variable is set then itspecifies a path to use instead of the default .gitfor the base of the repository.The —git-dir command-line option also sets this value.

  • GIT_WORK_TREE

  • Set the path to the root of the working tree.This can also be controlled by the —work-tree command-lineoption and the core.worktree configuration variable.

  • GIT_NAMESPACE

  • Set the Git namespace; see gitnamespaces[7] for details.The —namespace command-line option also sets this value.

  • GIT_CEILING_DIRECTORIES

  • This should be a colon-separated list of absolute paths. Ifset, it is a list of directories that Git should not chdir upinto while looking for a repository directory (useful forexcluding slow-loading network directories). It will notexclude the current working directory or a GIT_DIR set on thecommand line or in the environment. Normally, Git has to readthe entries in this list and resolve any symlink thatmight be present in order to compare them with the currentdirectory. However, if even this access is slow, youcan add an empty entry to the list to tell Git that thesubsequent entries are not symlinks and needn’t be resolved;e.g.,GIT_CEILING_DIRECTORIES=/maybe/symlink::/very/slow/non/symlink.

  • GIT_DISCOVERY_ACROSS_FILESYSTEM

  • When run in a directory that does not have ".git" repositorydirectory, Git tries to find such a directory in the parentdirectories to find the top of the working tree, but by default itdoes not cross filesystem boundaries. This environment variablecan be set to true to tell Git not to stop at filesystemboundaries. Like GIT_CEILING_DIRECTORIES, this will not affectan explicit repository directory set via GIT_DIR or on thecommand line.

  • GIT_COMMON_DIR

  • If this variable is set to a path, non-worktree files that arenormally in $GIT_DIR will be taken from this pathinstead. Worktree-specific files such as HEAD or index aretaken from $GIT_DIR. See gitrepository-layout[5] andgit-worktree[1] fordetails. This variable has lower precedence than other pathvariables such as GIT_INDEX_FILE, GIT_OBJECT_DIRECTORY…​

Git Commits

  • GIT_AUTHOR_NAME
  • GIT_AUTHOR_EMAIL
  • GIT_AUTHOR_DATE
  • GIT_COMMITTER_NAME
  • GIT_COMMITTER_EMAIL
  • GIT_COMMITTER_DATE
  • EMAIL
  • see git-commit-tree[1]

Git Diffs

  • GIT_DIFF_OPTS

  • Only valid setting is "—unified=??" or "-u??" to set thenumber of context lines shown when a unified diff is created.This takes precedence over any "-U" or "—unified" optionvalue passed on the Git diff command line.

  • GIT_EXTERNAL_DIFF

  • When the environment variable GIT_EXTERNAL_DIFF is set, theprogram named by it is called, instead of the diff invocationdescribed above. For a path that is added, removed, or modified,GIT_EXTERNAL_DIFF is called with 7 parameters:
  1. path old-file old-hex old-mode new-file new-hex new-mode

where:

  • -file

  • are files GIT_EXTERNAL_DIFF can use to read thecontents of ,

  • -hex

  • are the 40-hexdigit SHA-1 hashes,

  • -mode

  • are the octal representation of the file modes.

The file parameters can point at the user’s working file(e.g. new-file in "git-diff-files"), /dev/null (e.g. old-filewhen a new file is added), or a temporary file (e.g. old-file in theindex). GIT_EXTERNAL_DIFF should not worry about unlinking thetemporary file —- it is removed when GIT_EXTERNAL_DIFF exits.

For a path that is unmerged, GIT_EXTERNAL_DIFF is called with 1parameter, .

For each path GIT_EXTERNAL_DIFF is called, two environment variables,GIT_DIFF_PATH_COUNTER and GIT_DIFF_PATH_TOTAL are set.

  • GIT_DIFF_PATH_COUNTER

  • A 1-based counter incremented by one for every path.

  • GIT_DIFF_PATH_TOTAL

  • The total number of paths.

other

  • GIT_MERGE_VERBOSITY

  • A number controlling the amount of output shown bythe recursive merge strategy. Overrides merge.verbosity.See git-merge[1]

  • GIT_PAGER

  • This environment variable overrides $PAGER. If it is setto an empty string or to the value "cat", Git will not launcha pager. See also the core.pager option ingit-config[1].

  • GIT_EDITOR

  • This environment variable overrides $EDITOR and $VISUAL.It is used by several Git commands when, on interactive mode,an editor is to be launched. See also git-var[1]and the core.editor option in git-config[1].

  • GIT_SSH

  • GIT_SSH_COMMAND
  • If either of these environment variables is set then git fetch_and _git push will use the specified command instead of _ssh_when they need to connect to a remote system.The command-line parameters passed to the configured command aredetermined by the ssh variant. See ssh.variant option ingit-config[1] for details.

$GIT_SSH_COMMAND takes precedence over $GIT_SSH, and is interpretedby the shell, which allows additional arguments to be included.$GIT_SSH on the other hand must be just the path to a program(which can be a wrapper shell script, if additional arguments areneeded).

Usually it is easier to configure any desired options through yourpersonal .ssh/config file. Please consult your ssh documentationfor further details.

  • GIT_SSH_VARIANT

  • If this environment variable is set, it overrides Git’s autodetectionwhether GIT_SSH/GIT_SSH_COMMAND/core.sshCommand refer to OpenSSH,plink or tortoiseplink. This variable overrides the config settingssh.variant that serves the same purpose.

  • GIT_ASKPASS

  • If this environment variable is set, then Git commands which need toacquire passwords or passphrases (e.g. for HTTP or IMAP authentication)will call this program with a suitable prompt as command-line argumentand read the password from its STDOUT. See also the core.askPassoption in git-config[1].

  • GIT_TERMINAL_PROMPT

  • If this environment variable is set to 0, git will not prompton the terminal (e.g., when asking for HTTP authentication).

  • GIT_CONFIG_NOSYSTEM

  • Whether to skip reading settings from the system-wide$(prefix)/etc/gitconfig file. This environment variable canbe used along with $HOME and $XDG_CONFIG_HOME to create apredictable environment for a picky script, or you can set ittemporarily to avoid using a buggy /etc/gitconfig file whilewaiting for someone with sufficient permissions to fix it.

  • GIT_FLUSH

  • If this environment variable is set to "1", then commands suchas git blame (in incremental mode), git rev-list, git log,git check-attr and git check-ignore willforce a flush of the output stream after each record have beenflushed. If thisvariable is set to "0", the output of these commands will be doneusing completely buffered I/O. If this environment variable isnot set, Git will choose buffered or record-oriented flushingbased on whether stdout appears to be redirected to a file or not.

  • GIT_TRACE

  • Enables general trace messages, e.g. alias expansion, built-incommand execution and external command execution.

If this variable is set to "1", "2" or "true" (comparisonis case insensitive), trace messages will be printed tostderr.

If the variable is set to an integer value greater than 2and lower than 10 (strictly) then Git will interpret thisvalue as an open file descriptor and will try to write thetrace messages into this file descriptor.

Alternatively, if the variable is set to an absolute path(starting with a / character), Git will interpret thisas a file path and will try to append the trace messagesto it.

Unsetting the variable, or setting it to empty, "0" or"false" (case insensitive) disables trace messages.

  • GIT_TRACE_FSMONITOR

  • Enables trace messages for the filesystem monitor extension.See GIT_TRACE for available trace output options.

  • GIT_TRACE_PACK_ACCESS

  • Enables trace messages for all accesses to any packs. For eachaccess, the pack file name and an offset in the pack isrecorded. This may be helpful for troubleshooting somepack-related performance problems.See GIT_TRACE for available trace output options.

  • GIT_TRACE_PACKET

  • Enables trace messages for all packets coming in or out of agiven program. This can help with debugging object negotiationor other protocol issues. Tracing is turned off at a packetstarting with "PACK" (but see GIT_TRACE_PACKFILE below).See GIT_TRACE for available trace output options.

  • GIT_TRACE_PACKFILE

  • Enables tracing of packfiles sent or received by agiven program. Unlike other trace output, this trace isverbatim: no headers, and no quoting of binary data. You almostcertainly want to direct into a file (e.g.,GIT_TRACE_PACKFILE=/tmp/my.pack) rather than displaying it onthe terminal or mixing it with other trace output.

Note that this is currently only implemented for the client sideof clones and fetches.

  • GIT_TRACE_PERFORMANCE

  • Enables performance related trace messages, e.g. total executiontime of each Git command.See GIT_TRACE for available trace output options.

  • GIT_TRACE_SETUP

  • Enables trace messages printing the .git, working tree and currentworking directory after Git has completed its setup phase.See GIT_TRACE for available trace output options.

  • GIT_TRACE_SHALLOW

  • Enables trace messages that can help debugging fetching /cloning of shallow repositories.See GIT_TRACE for available trace output options.

  • GIT_TRACE_CURL

  • Enables a curl full trace dump of all incoming and outgoing data,including descriptive information, of the git transport protocol.This is similar to doing curl —trace-ascii on the command line.This option overrides setting the GIT_CURL_VERBOSE environmentvariable.See GIT_TRACE for available trace output options.

  • GIT_TRACE_CURL_NO_DATA

  • When a curl trace is enabled (see GIT_TRACE_CURL above), do not dumpdata (that is, only dump info lines and headers).

  • GIT_TRACE2

  • Enables more detailed trace messages from the "trace2" library.Output from GIT_TRACE2 is a simple text-based format for humanreadability.

If this variable is set to "1", "2" or "true" (comparisonis case insensitive), trace messages will be printed tostderr.

If the variable is set to an integer value greater than 2and lower than 10 (strictly) then Git will interpret thisvalue as an open file descriptor and will try to write thetrace messages into this file descriptor.

Alternatively, if the variable is set to an absolute path(starting with a / character), Git will interpret thisas a file path and will try to append the trace messagesto it. If the path already exists and is a directory, thetrace messages will be written to files (one per process)in that directory, named according to the last componentof the SID and an optional counter (to avoid filenamecollisions).

In addition, if the variable is set toaf_unix:[<socket_type>:]<absolute-pathname>, Git will tryto open the path as a Unix Domain Socket. The socket typecan be either stream or dgram.

Unsetting the variable, or setting it to empty, "0" or"false" (case insensitive) disables trace messages.

See Trace2 documentationfor full details.

  • GIT_TRACE2_EVENT

  • This setting writes a JSON-based format that is suited for machineinterpretation.See GIT_TRACE2 for available trace output options andTrace2 documentation for full details.

  • GIT_TRACE2_PERF

  • In addition to the text-based messages available in GIT_TRACE2, thissetting writes a column-based format for understanding nestingregions.See GIT_TRACE2 for available trace output options andTrace2 documentation for full details.

  • GIT_REDACT_COOKIES

  • This can be set to a comma-separated list of strings. When a curl traceis enabled (see GIT_TRACE_CURL above), whenever a "Cookies:" headersent by the client is dumped, values of cookies whose key is in thatlist (case-sensitive) are redacted.

  • GIT_LITERAL_PATHSPECS

  • Setting this variable to 1 will cause Git to treat allpathspecs literally, rather than as glob patterns. For example,running GIT_LITERAL_PATHSPECS=1 git log — '.c' will searchfor commits that touch the path .c, not any paths that theglob *.c matches. You might want this if you are feedingliteral paths to Git (e.g., paths previously given to you bygit ls-tree, —raw diff output, etc).

  • GIT_GLOB_PATHSPECS

  • Setting this variable to 1 will cause Git to treat allpathspecs as glob patterns (aka "glob" magic).

  • GIT_NOGLOB_PATHSPECS

  • Setting this variable to 1 will cause Git to treat allpathspecs as literal (aka "literal" magic).

  • GIT_ICASE_PATHSPECS

  • Setting this variable to 1 will cause Git to treat allpathspecs as case-insensitive.

  • GIT_REFLOG_ACTION

  • When a ref is updated, reflog entries are created to keeptrack of the reason why the ref was updated (which istypically the name of the high-level command that updatedthe ref), in addition to the old and new values of the ref.A scripted Porcelain command can use set_reflog_actionhelper function in git-sh-setup to set its name to thisvariable when it is invoked as the top level command by theend user, to be recorded in the body of the reflog.

  • GIT_REF_PARANOIA

  • If set to 1, include broken or badly named refs when iteratingover lists of refs. In a normal, non-corrupted repository, thisdoes nothing. However, enabling it may help git to detect andabort some operations in the presence of broken refs. Git setsthis variable automatically when performing destructiveoperations like git-prune[1]. You should not need to setit yourself unless you want to be paranoid about making surean operation has touched every ref (e.g., because you arecloning a repository to make a backup).

  • GIT_ALLOW_PROTOCOL

  • If set to a colon-separated list of protocols, behave as ifprotocol.allow is set to never, and each of the listedprotocols has protocol.<name>.allow set to always(overriding any existing configuration). In other words, anyprotocol not mentioned will be disallowed (i.e., this is awhitelist, not a blacklist). See the description ofprotocol.allow in git-config[1] for more details.

  • GIT_PROTOCOL_FROM_USER

  • Set to 0 to prevent protocols used by fetch/push/clone which areconfigured to the user state. This is useful to restrict recursivesubmodule initialization from an untrusted repository or for programswhich feed potentially-untrusted URLS to git commands. Seegit-config[1] for more details.

  • GIT_PROTOCOL

  • For internal use only. Used in handshaking the wire protocol.Contains a colon : separated list of keys with optional valueskey[=value]. Presence of unknown keys and values must beignored.

  • GIT_OPTIONAL_LOCKS

  • If set to 0, Git will complete any requested operation withoutperforming any optional sub-operations that require taking a lock.For example, this will prevent git status from refreshing theindex as a side effect. This is useful for processes running inthe background which do not want to cause lock contention withother operations on the repository. Defaults to 1.

  • GIT_REDIRECT_STDIN

  • GIT_REDIRECT_STDOUT
  • GIT_REDIRECT_STDERR
  • Windows-only: allow redirecting the standard input/output/errorhandles to paths specified by the environment variables. This isparticularly useful in multi-threaded applications where thecanonical way to pass standard handles via CreateProcess() isnot an option because it would require the handles to be markedinheritable (and consequently every spawned process wouldinherit them, possibly blocking regular Git operations). Theprimary intended use case is to use named pipes for communication(e.g. \.\pipe\my-git-stdin-123).

Two special values are supported: off will simply close thecorresponding standard handle, and if GIT_REDIRECT_STDERR is2>&1, standard error will be redirected to the same handle asstandard output.

  • GIT_PRINT_SHA1_ELLIPSIS (deprecated)
  • If set to yes, print an ellipsis following an(abbreviated) SHA-1 value. This affects indications ofdetached HEADs (git-checkout[1]) and the rawdiff output (git-diff[1]). Printing anellipsis in the cases mentioned is no longer consideredadequate and support for it is likely to be removed in theforeseeable future (along with the variable).

Discussion

More detail on the following is available from theGit concepts chapter of theuser-manual and gitcore-tutorial[7].

A Git project normally consists of a working directory with a ".git"subdirectory at the top level. The .git directory contains, among otherthings, a compressed object database representing the complete historyof the project, an "index" file which links that history to the currentcontents of the working tree, and named pointers into that history suchas tags and branch heads.

The object database contains objects of three main types: blobs, whichhold file data; trees, which point to blobs and other trees to build updirectory hierarchies; and commits, which each reference a single treeand some number of parent commits.

The commit, equivalent to what other systems call a "changeset" or"version", represents a step in the project’s history, and each parentrepresents an immediately preceding step. Commits with more than oneparent represent merges of independent lines of development.

All objects are named by the SHA-1 hash of their contents, normallywritten as a string of 40 hex digits. Such names are globally unique.The entire history leading up to a commit can be vouched for by signingjust that commit. A fourth object type, the tag, is provided for thispurpose.

When first created, objects are stored in individual files, but forefficiency may later be compressed together into "pack files".

Named pointers called refs mark interesting points in history. A refmay contain the SHA-1 name of an object or the name of another ref. Refswith names beginning ref/head/ contain the SHA-1 name of the mostrecent commit (or "head") of a branch under development. SHA-1 names oftags of interest are stored under ref/tags/. A special ref namedHEAD contains the name of the currently checked-out branch.

The index file is initialized with a list of all paths and, for eachpath, a blob object and a set of attributes. The blob object representsthe contents of the file as of the head of the current branch. Theattributes (last modified time, size, etc.) are taken from thecorresponding file in the working tree. Subsequent changes to theworking tree can be found by comparing these attributes. The index maybe updated with new content, and new commits may be created from thecontent stored in the index.

The index is also capable of storing multiple entries (called "stages")for a given pathname. These stages are used to hold the variousunmerged version of a file when a merge is in progress.

FURTHER DOCUMENTATION

See the references in the "description" section to get startedusing Git. The following is probably more detail than necessaryfor a first-time user.

The Git concepts chapter of theuser-manual and gitcore-tutorial[7] both provideintroductions to the underlying Git architecture.

See gitworkflows[7] for an overview of recommended workflows.

See also the howto documents for some usefulexamples.

The internals are documented in theGit API documentation.

Users migrating from CVS may also want toread gitcvs-migration[7].

Authors

Git was started by Linus Torvalds, and is currently maintained by JunioC Hamano. Numerous contributions have come from the Git mailing list<git@vger.kernel.org>. http://www.openhub.net/p/git/contributors/summarygives you a more complete list of contributors.

If you have a clone of git.git itself, theoutput of git-shortlog[1] and git-blame[1] can show youthe authors for specific parts of the project.

Reporting Bugs

Report bugs to the Git mailing list <git@vger.kernel.org> where thedevelopment and maintenance is primarily done. You do not have to besubscribed to the list to send a message there. See the list archiveat https://public-inbox.org/git for previous bug reports and otherdiscussions.

Issues which are security relevant should be disclosed privately tothe Git Security mailing list <git-security@googlegroups.com>.

SEE ALSO

gittutorial[7], gittutorial-2[7],giteveryday[7], gitcvs-migration[7],gitglossary[7], gitcore-tutorial[7],gitcli[7], The Git User’s Manual,gitworkflows[7]

GIT

Part of the git[1] suite