Documentation/git-commit.txt

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