Documentation / git-commit.txton commit Align section headers of 'git status' to new 'git add'. (82dca84)
   1git-commit(1)
   2=============
   3
   4NAME
   5----
   6git-commit - Record your changes
   7
   8SYNOPSIS
   9--------
  10[verse]
  11'git-commit' [-a] [-s] [-v] [(-c | -C) <commit> | -F <file> | -m <msg>]
  12           [--no-verify] [--amend] [-e] [--author <author>]
  13           [--] [[-i | -o ]<file>...]
  14
  15DESCRIPTION
  16-----------
  17Use 'git commit' when you want to record your changes into the repository
  18along with a log message describing what the commit is about. All changes
  19to be committed must be explicitly identified using one of the following
  20methods:
  21
  221. by using gitlink:git-add[1] to incrementally "add" changes to the
  23   next commit before using the 'commit' command (Note: even modified
  24   files must be "added");
  25
  262. by using gitlink:git-rm[1] to identify content removal for the next
  27   commit, again before using the 'commit' command;
  28
  293. by directly listing files containing changes to be committed as arguments
  30   to the 'commit' command, in which cases only those files alone will be
  31   considered for the commit;
  32
  334. by using the -a switch with the 'commit' command to automatically "add"
  34   changes from all known files i.e. files that have already been committed
  35   before, and perform the actual commit.
  36
  37The gitlink:git-status[1] command can be used to obtain a
  38summary of what is included by any of the above for the next
  39commit by giving the same set of parameters you would give to
  40this command.
  41
  42If you make a commit and then found a mistake immediately after
  43that, you can recover from it with gitlink:git-reset[1].
  44
  45
  46OPTIONS
  47-------
  48-a|--all::
  49        Tell the command to automatically stage files that have
  50        been modified and deleted, but new files you have not
  51        told git about are not affected.
  52
  53-c or -C <commit>::
  54        Take existing commit object, and reuse the log message
  55        and the authorship information (including the timestamp)
  56        when creating the commit.  With '-C', the editor is not
  57        invoked; with '-c' the user can further edit the commit
  58        message.
  59
  60-F <file>::
  61        Take the commit message from the given file.  Use '-' to
  62        read the message from the standard input.
  63
  64--author <author>::
  65        Override the author name used in the commit.  Use
  66        `A U Thor <author@example.com>` format.
  67
  68-m <msg>::
  69        Use the given <msg> as the commit message.
  70
  71-s|--signoff::
  72        Add Signed-off-by line at the end of the commit message.
  73
  74--no-verify::
  75        By default, the command looks for suspicious lines the
  76        commit introduces, and aborts committing if there is one.
  77        The definition of 'suspicious lines' is currently the
  78        lines that has trailing whitespaces, and the lines whose
  79        indentation has a SP character immediately followed by a
  80        TAB character.  This option turns off the check.
  81
  82-e|--edit::
  83        The message taken from file with `-F`, command line with
  84        `-m`, and from file with `-C` are usually used as the
  85        commit log message unmodified.  This option lets you
  86        further edit the message taken from these sources.
  87
  88--amend::
  89
  90        Used to amend the tip of the current branch. Prepare the tree
  91        object you would want to replace the latest commit as usual
  92        (this includes the usual -i/-o and explicit paths), and the
  93        commit log editor is seeded with the commit message from the
  94        tip of the current branch. The commit you create replaces the
  95        current tip -- if it was a merge, it will have the parents of
  96        the current tip as parents -- so the current top commit is
  97        discarded.
  98+
  99--
 100It is a rough equivalent for:
 101------
 102        $ git reset --soft HEAD^
 103        $ ... do something else to come up with the right tree ...
 104        $ git commit -c ORIG_HEAD
 105
 106------
 107but can be used to amend a merge commit.
 108--
 109
 110-i|--include::
 111        Before making a commit out of staged contents so far,
 112        stage the contents of paths given on the command line
 113        as well.  This is usually not what you want unless you
 114        are concluding a conflicted merge.
 115
 116-q|--quiet::
 117        Supress commit summary message.
 118
 119\--::
 120        Do not interpret any more arguments as options.
 121
 122<file>...::
 123        When files are given on the command line, the command
 124        commits the contents of the named files, without
 125        recording the changes already staged.  The contents of
 126        these files are also staged for the next commit on top
 127        of what have been staged before.
 128
 129
 130EXAMPLES
 131--------
 132When recording your own work, the contents of modified files in
 133your working tree are temporarily stored to a staging area
 134called the "index" with gitlink:git-add[1].  Removal
 135of a file is staged with gitlink:git-rm[1].  After building the
 136state to be committed incrementally with these commands, `git
 137commit` (without any pathname parameter) is used to record what
 138has been staged so far.  This is the most basic form of the
 139command.  An example:
 140
 141------------
 142$ edit hello.c
 143$ git rm goodbye.c
 144$ git add hello.c
 145$ git commit
 146------------
 147
 148////////////
 149We should fix 'git rm' to remove goodbye.c from both index and
 150working tree for the above example.
 151////////////
 152
 153Instead of staging files after each individual change, you can
 154tell `git commit` to notice the changes to the files whose
 155contents are tracked in
 156your working tree and do corresponding `git add` and `git rm`
 157for you.  That is, this example does the same as the earlier
 158example if there is no other change in your working tree:
 159
 160------------
 161$ edit hello.c
 162$ rm goodbye.c
 163$ git commit -a
 164------------
 165
 166The command `git commit -a` first looks at your working tree,
 167notices that you have modified hello.c and removed goodbye.c,
 168and performs necessary `git add` and `git rm` for you.
 169
 170After staging changes to many files, you can alter the order the
 171changes are recorded in, by giving pathnames to `git commit`.
 172When pathnames are given, the command makes a commit that
 173only records the changes made to the named paths:
 174
 175------------
 176$ edit hello.c hello.h
 177$ git add hello.c hello.h
 178$ edit Makefile
 179$ git commit Makefile
 180------------
 181
 182This makes a commit that records the modification to `Makefile`.
 183The changes staged for `hello.c` and `hello.h` are not included
 184in the resulting commit.  However, their changes are not lost --
 185they are still staged and merely held back.  After the above
 186sequence, if you do:
 187
 188------------
 189$ git commit
 190------------
 191
 192this second commit would record the changes to `hello.c` and
 193`hello.h` as expected.
 194
 195After a merge (initiated by either gitlink:git-merge[1] or
 196gitlink:git-pull[1]) stops because of conflicts, cleanly merged
 197paths are already staged to be committed for you, and paths that
 198conflicted are left in unmerged state.  You would have to first
 199check which paths are conflicting with gitlink:git-status[1]
 200and after fixing them manually in your working tree, you would
 201stage the result as usual with gitlink:git-add[1]:
 202
 203------------
 204$ git status | grep unmerged
 205unmerged: hello.c
 206$ edit hello.c
 207$ git add hello.c
 208------------
 209
 210After resolving conflicts and staging the result, `git ls-files -u`
 211would stop mentioning the conflicted path.  When you are done,
 212run `git commit` to finally record the merge:
 213
 214------------
 215$ git commit
 216------------
 217
 218As with the case to record your own changes, you can use `-a`
 219option to save typing.  One difference is that during a merge
 220resolution, you cannot use `git commit` with pathnames to
 221alter the order the changes are committed, because the merge
 222should be recorded as a single commit.  In fact, the command
 223refuses to run when given pathnames (but see `-i` option).
 224
 225
 226ENVIRONMENT VARIABLES
 227---------------------
 228The command specified by either the VISUAL or EDITOR environment
 229variables is used to edit the commit log message.
 230
 231HOOKS
 232-----
 233This command can run `commit-msg`, `pre-commit`, and
 234`post-commit` hooks.  See link:hooks.html[hooks] for more
 235information.
 236
 237
 238SEE ALSO
 239--------
 240gitlink:git-add[1],
 241gitlink:git-rm[1],
 242gitlink:git-mv[1],
 243gitlink:git-merge[1],
 244gitlink:git-commit-tree[1]
 245
 246Author
 247------
 248Written by Linus Torvalds <torvalds@osdl.org> and
 249Junio C Hamano <junkio@cox.net>
 250
 251
 252GIT
 253---
 254Part of the gitlink:git[7] suite