git/Documentation/git-commit.txt

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