d01ff5adaec400e84565e1d62a29686f4c1d6db5
   1git-commit(1)
   2=============
   3
   4NAME
   5----
   6git-commit - Record changes to the repository
   7
   8SYNOPSIS
   9--------
  10[verse]
  11'git commit' [-a | --interactive] [-s] [-v] [-u<mode>] [--amend] [--dry-run]
  12           [(-c | -C) <commit>] [-F <file> | -m <msg>]
  13           [--allow-empty] [--no-verify] [-e] [--author=<author>]
  14           [--cleanup=<mode>] [--] [[-i | -o ]<file>...]
  15
  16DESCRIPTION
  17-----------
  18Stores the current contents of the index in a new commit along
  19with a log message from the user describing the changes.
  20
  21The content to be added can be specified in several ways:
  22
  231. by using 'git-add' to incrementally "add" changes to the
  24   index before using the 'commit' command (Note: even modified
  25   files must be "added");
  26
  272. by using 'git-rm' to remove files from the working tree
  28   and the index, again before using the 'commit' command;
  29
  303. by listing files as arguments to the 'commit' command, in which
  31   case the commit will ignore changes staged in the index, and instead
  32   record the current content of the listed files (which must already
  33   be known to git);
  34
  354. by using the -a switch with the 'commit' command to automatically
  36   "add" changes from all known files (i.e. all files that are already
  37   listed in the index) and to automatically "rm" files in the index
  38   that have been removed from the working tree, and then perform the
  39   actual commit;
  40
  415. by using the --interactive switch with the 'commit' command to decide one
  42   by one which files should be part of the commit, before finalizing the
  43   operation.  Currently, this is done by invoking 'git-add --interactive'.
  44
  45The 'git-status' command can be used to obtain a
  46summary of what is included by any of the above for the next
  47commit by giving the same set of parameters you would give to
  48this command.
  49
  50If you make a commit and then find a mistake immediately after
  51that, you can recover from it with 'git-reset'.
  52
  53
  54OPTIONS
  55-------
  56-a::
  57--all::
  58        Tell the command to automatically stage files that have
  59        been modified and deleted, but new files you have not
  60        told git about are not affected.
  61
  62-C <commit>::
  63--reuse-message=<commit>::
  64        Take an existing commit object, and reuse the log message
  65        and the authorship information (including the timestamp)
  66        when creating the commit.
  67
  68-c <commit>::
  69--reedit-message=<commit>::
  70        Like '-C', but with '-c' the editor is invoked, so that
  71        the user can further edit the commit message.
  72
  73-F <file>::
  74--file=<file>::
  75        Take the commit message from the given file.  Use '-' to
  76        read the message from the standard input.
  77
  78--author=<author>::
  79        Override the author name used in the commit.  You can use the
  80        standard `A U Thor <author@example.com>` format.  Otherwise,
  81        an existing commit that matches the given string and its author
  82        name is used.
  83
  84-m <msg>::
  85--message=<msg>::
  86        Use the given <msg> as the commit message.
  87
  88-t <file>::
  89--template=<file>::
  90        Use the contents of the given file as the initial version
  91        of the commit message. The editor is invoked and you can
  92        make subsequent changes. If a message is specified using
  93        the `-m` or `-F` options, this option has no effect. This
  94        overrides the `commit.template` configuration variable.
  95
  96-s::
  97--signoff::
  98        Add Signed-off-by line by the committer at the end of the commit
  99        log message.
 100
 101-n::
 102--no-verify::
 103        This option bypasses the pre-commit and commit-msg hooks.
 104        See also linkgit:githooks[5].
 105
 106--allow-empty::
 107        Usually recording a commit that has the exact same tree as its
 108        sole parent commit is a mistake, and the command prevents you
 109        from making such a commit.  This option bypasses the safety, and
 110        is primarily for use by foreign scm interface scripts.
 111
 112--cleanup=<mode>::
 113        This option sets how the commit message is cleaned up.
 114        The  '<mode>' can be one of 'verbatim', 'whitespace', 'strip',
 115        and 'default'. The 'default' mode will strip leading and
 116        trailing empty lines and #commentary from the commit message
 117        only if the message is to be edited. Otherwise only whitespace
 118        removed. The 'verbatim' mode does not change message at all,
 119        'whitespace' removes just leading/trailing whitespace lines
 120        and 'strip' removes both whitespace and commentary.
 121
 122-e::
 123--edit::
 124        The message taken from file with `-F`, command line with
 125        `-m`, and from file with `-C` are usually used as the
 126        commit log message unmodified.  This option lets you
 127        further edit the message taken from these sources.
 128
 129--amend::
 130        Used to amend the tip of the current branch. Prepare the tree
 131        object you would want to replace the latest commit as usual
 132        (this includes the usual -i/-o and explicit paths), and the
 133        commit log editor is seeded with the commit message from the
 134        tip of the current branch. The commit you create replaces the
 135        current tip -- if it was a merge, it will have the parents of
 136        the current tip as parents -- so the current top commit is
 137        discarded.
 138+
 139--
 140It is a rough equivalent for:
 141------
 142        $ git reset --soft HEAD^
 143        $ ... do something else to come up with the right tree ...
 144        $ git commit -c ORIG_HEAD
 145
 146------
 147but can be used to amend a merge commit.
 148--
 149+
 150You should understand the implications of rewriting history if you
 151amend a commit that has already been published.  (See the "RECOVERING
 152FROM UPSTREAM REBASE" section in linkgit:git-rebase[1].)
 153
 154-i::
 155--include::
 156        Before making a commit out of staged contents so far,
 157        stage the contents of paths given on the command line
 158        as well.  This is usually not what you want unless you
 159        are concluding a conflicted merge.
 160
 161-o::
 162--only::
 163        Make a commit only from the paths specified on the
 164        command line, disregarding any contents that have been
 165        staged so far. This is the default mode of operation of
 166        'git-commit' if any paths are given on the command line,
 167        in which case this option can be omitted.
 168        If this option is specified together with '--amend', then
 169        no paths need to be specified, which can be used to amend
 170        the last commit without committing changes that have
 171        already been staged.
 172
 173-u[<mode>]::
 174--untracked-files[=<mode>]::
 175        Show untracked files (Default: 'all').
 176+
 177The mode parameter is optional, and is used to specify
 178the handling of untracked files. The possible options are:
 179+
 180--
 181        - 'no'     - Show no untracked files
 182        - 'normal' - Shows untracked files and directories
 183        - 'all'    - Also shows individual files in untracked directories.
 184--
 185+
 186See linkgit:git-config[1] for configuration variable
 187used to change the default for when the option is not
 188specified.
 189
 190-v::
 191--verbose::
 192        Show unified diff between the HEAD commit and what
 193        would be committed at the bottom of the commit message
 194        template.  Note that this diff output doesn't have its
 195        lines prefixed with '#'.
 196
 197-q::
 198--quiet::
 199        Suppress commit summary message.
 200
 201--dry-run::
 202        Do not create a commit, but show a list of paths that are
 203        to be committed, paths with local changes that will be left
 204        uncommitted and paths that are untracked.
 205
 206\--::
 207        Do not interpret any more arguments as options.
 208
 209<file>...::
 210        When files are given on the command line, the command
 211        commits the contents of the named files, without
 212        recording the changes already staged.  The contents of
 213        these files are also staged for the next commit on top
 214        of what have been staged before.
 215
 216
 217EXAMPLES
 218--------
 219When recording your own work, the contents of modified files in
 220your working tree are temporarily stored to a staging area
 221called the "index" with 'git-add'.  A file can be
 222reverted back, only in the index but not in the working tree,
 223to that of the last commit with `git reset HEAD -- <file>`,
 224which effectively reverts 'git-add' and prevents the changes to
 225this file from participating in the next commit.  After building
 226the state to be committed incrementally with these commands,
 227`git commit` (without any pathname parameter) is used to record what
 228has been staged so far.  This is the most basic form of the
 229command.  An example:
 230
 231------------
 232$ edit hello.c
 233$ git rm goodbye.c
 234$ git add hello.c
 235$ git commit
 236------------
 237
 238Instead of staging files after each individual change, you can
 239tell `git commit` to notice the changes to the files whose
 240contents are tracked in
 241your working tree and do corresponding `git add` and `git rm`
 242for you.  That is, this example does the same as the earlier
 243example if there is no other change in your working tree:
 244
 245------------
 246$ edit hello.c
 247$ rm goodbye.c
 248$ git commit -a
 249------------
 250
 251The command `git commit -a` first looks at your working tree,
 252notices that you have modified hello.c and removed goodbye.c,
 253and performs necessary `git add` and `git rm` for you.
 254
 255After staging changes to many files, you can alter the order the
 256changes are recorded in, by giving pathnames to `git commit`.
 257When pathnames are given, the command makes a commit that
 258only records the changes made to the named paths:
 259
 260------------
 261$ edit hello.c hello.h
 262$ git add hello.c hello.h
 263$ edit Makefile
 264$ git commit Makefile
 265------------
 266
 267This makes a commit that records the modification to `Makefile`.
 268The changes staged for `hello.c` and `hello.h` are not included
 269in the resulting commit.  However, their changes are not lost --
 270they are still staged and merely held back.  After the above
 271sequence, if you do:
 272
 273------------
 274$ git commit
 275------------
 276
 277this second commit would record the changes to `hello.c` and
 278`hello.h` as expected.
 279
 280After a merge (initiated by 'git-merge' or 'git-pull') stops
 281because of conflicts, cleanly merged
 282paths are already staged to be committed for you, and paths that
 283conflicted are left in unmerged state.  You would have to first
 284check which paths are conflicting with 'git-status'
 285and after fixing them manually in your working tree, you would
 286stage the result as usual with 'git-add':
 287
 288------------
 289$ git status | grep unmerged
 290unmerged: hello.c
 291$ edit hello.c
 292$ git add hello.c
 293------------
 294
 295After resolving conflicts and staging the result, `git ls-files -u`
 296would stop mentioning the conflicted path.  When you are done,
 297run `git commit` to finally record the merge:
 298
 299------------
 300$ git commit
 301------------
 302
 303As with the case to record your own changes, you can use `-a`
 304option to save typing.  One difference is that during a merge
 305resolution, you cannot use `git commit` with pathnames to
 306alter the order the changes are committed, because the merge
 307should be recorded as a single commit.  In fact, the command
 308refuses to run when given pathnames (but see `-i` option).
 309
 310
 311DISCUSSION
 312----------
 313
 314Though not required, it's a good idea to begin the commit message
 315with a single short (less than 50 character) line summarizing the
 316change, followed by a blank line and then a more thorough description.
 317Tools that turn commits into email, for example, use the first line
 318on the Subject: line and the rest of the commit in the body.
 319
 320include::i18n.txt[]
 321
 322ENVIRONMENT AND CONFIGURATION VARIABLES
 323---------------------------------------
 324The editor used to edit the commit log message will be chosen from the
 325GIT_EDITOR environment variable, the core.editor configuration variable, the
 326VISUAL environment variable, or the EDITOR environment variable (in that
 327order).
 328
 329HOOKS
 330-----
 331This command can run `commit-msg`, `prepare-commit-msg`, `pre-commit`,
 332and `post-commit` hooks.  See linkgit:githooks[5] for more
 333information.
 334
 335
 336SEE ALSO
 337--------
 338linkgit:git-add[1],
 339linkgit:git-rm[1],
 340linkgit:git-mv[1],
 341linkgit:git-merge[1],
 342linkgit:git-commit-tree[1]
 343
 344Author
 345------
 346Written by Linus Torvalds <torvalds@osdl.org> and
 347Junio C Hamano <gitster@pobox.com>
 348
 349
 350GIT
 351---
 352Part of the linkgit:git[1] suite