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