| 1 | git-commit(1) |
| 2 | ============= |
| 3 | |
| 4 | NAME |
| 5 | ---- |
| 6 | git-commit - Record changes to the repository |
| 7 | |
| 8 | SYNOPSIS |
| 9 | -------- |
| 10 | [synopsis] |
| 11 | git commit [-a | --interactive | --patch] [-s] [-v] [-u[<mode>]] [--amend] |
| 12 | [--dry-run] [(-c | -C | --squash) <commit> | --fixup [(amend|reword):]<commit>] |
| 13 | [-F <file> | -m <msg>] [--reset-author] [--allow-empty] |
| 14 | [--allow-empty-message] [--no-verify] [-e] [--author=<author>] |
| 15 | [--date=<date>] [--cleanup=<mode>] [--[no-]status] |
| 16 | [-i | -o] [--pathspec-from-file=<file> [--pathspec-file-nul]] |
| 17 | [(--trailer <token>[(=|:)<value>])...] [-S[<keyid>]] |
| 18 | [--] [<pathspec>...] |
| 19 | |
| 20 | DESCRIPTION |
| 21 | ----------- |
| 22 | Create a new commit containing the current contents of the index and |
| 23 | the given log message describing the changes. The new commit is a |
| 24 | direct child of HEAD, usually the tip of the current branch, and the |
| 25 | branch is updated to point to it (unless no branch is associated with |
| 26 | the working tree, in which case `HEAD` is "detached" as described in |
| 27 | linkgit:git-checkout[1]). |
| 28 | |
| 29 | The content to be committed can be specified in several ways: |
| 30 | |
| 31 | 1. by using linkgit:git-add[1] to incrementally "add" changes to the |
| 32 | index before using the `commit` command (Note: even modified files |
| 33 | must be "added"); |
| 34 | |
| 35 | 2. by using linkgit:git-rm[1] to remove files from the working tree |
| 36 | and the index, again before using the `commit` command; |
| 37 | |
| 38 | 3. by listing files as arguments to the `commit` command |
| 39 | (without `--interactive` or `--patch` switch), in which |
| 40 | case the commit will ignore changes staged in the index, and instead |
| 41 | record the current content of the listed files (which must already |
| 42 | be known to Git); |
| 43 | |
| 44 | 4. by using the `-a` switch with the `commit` command to automatically |
| 45 | "add" changes from all known files (i.e. all files that are already |
| 46 | listed in the index) and to automatically "rm" files in the index |
| 47 | that have been removed from the working tree, and then perform the |
| 48 | actual commit; |
| 49 | |
| 50 | 5. by using the `--interactive` or `--patch` switches with the `commit` command |
| 51 | to decide one by one which files or hunks should be part of the commit |
| 52 | in addition to contents in the index, |
| 53 | before finalizing the operation. See the ``Interactive Mode'' section of |
| 54 | linkgit:git-add[1] to learn how to operate these modes. |
| 55 | |
| 56 | The `--dry-run` option can be used to obtain a |
| 57 | summary of what is included by any of the above for the next |
| 58 | commit by giving the same set of parameters (options and paths). |
| 59 | |
| 60 | If you make a commit and then find a mistake immediately after |
| 61 | that, you can recover from it with `git reset`. |
| 62 | |
| 63 | :git-commit: 1 |
| 64 | |
| 65 | OPTIONS |
| 66 | ------- |
| 67 | `-a`:: |
| 68 | `--all`:: |
| 69 | Automatically stage files that have |
| 70 | been modified and deleted, but new files you have not |
| 71 | told Git about are not affected. |
| 72 | |
| 73 | `-p`:: |
| 74 | `--patch`:: |
| 75 | Use the interactive patch selection interface to choose |
| 76 | which changes to commit. See linkgit:git-add[1] for |
| 77 | details. |
| 78 | |
| 79 | include::diff-context-options.adoc[] |
| 80 | |
| 81 | `-C <commit>`:: |
| 82 | `--reuse-message=<commit>`:: |
| 83 | Take an existing _<commit>_ object, and reuse the log message |
| 84 | and the authorship information (including the timestamp) |
| 85 | when creating the commit. |
| 86 | |
| 87 | `-c <commit>`:: |
| 88 | `--reedit-message=<commit>`:: |
| 89 | Like `-C`, but with `-c` the editor is invoked, so that |
| 90 | the user can further edit the commit message. |
| 91 | |
| 92 | `--fixup=[(amend|reword):]<commit>`:: |
| 93 | Create a new commit which "fixes up" _<commit>_ when applied with |
| 94 | `git rebase --autosquash`. Plain `--fixup=<commit>` creates a |
| 95 | "fixup!" commit which changes the content of _<commit>_ but leaves |
| 96 | its log message untouched. `--fixup=amend:<commit>` is similar but |
| 97 | creates an "amend!" commit which also replaces the log message of |
| 98 | _<commit>_ with the log message of the "amend!" commit. |
| 99 | `--fixup=reword:<commit>` creates an "amend!" commit which |
| 100 | replaces the log message of _<commit>_ with its own log message |
| 101 | but makes no changes to the content of _<commit>_. |
| 102 | + |
| 103 | The commit created by plain `--fixup=<commit>` has a title |
| 104 | composed of "fixup!" followed by the title of _<commit>_, |
| 105 | and is recognized specially by `git rebase --autosquash`. The `-m`, |
| 106 | `-F`, `-C`, or `-c` option may be used to supplement the log message |
| 107 | of the created commit, but the additional commentary will be thrown |
| 108 | away once the "fixup!" commit is squashed into _<commit>_ by |
| 109 | `git rebase --autosquash`. |
| 110 | + |
| 111 | The commit created by `--fixup=amend:<commit>` is similar but its |
| 112 | title is instead prefixed with "amend!". The log message of |
| 113 | _<commit>_ is copied into the log message of the "amend!" commit and |
| 114 | opened in an editor so it can be refined. The replacement message may |
| 115 | also be supplied directly using `-m`, `-F`, or `-C`, bypassing the |
| 116 | need to open an editor, or using `-c` to open the editor pre-populated |
| 117 | with the referenced commit's message. When `git rebase |
| 118 | --autosquash` squashes the "amend!" commit into _<commit>_, the log |
| 119 | message of _<commit>_ is replaced by the refined log message from the |
| 120 | "amend!" commit. It is an error for the "amend!" commit's log message |
| 121 | to be empty unless `--allow-empty-message` is specified. |
| 122 | + |
| 123 | `--fixup=reword:<commit>` is shorthand for `--fixup=amend:<commit> |
| 124 | --only`. It creates an "amend!" commit with only a log message |
| 125 | (ignoring any changes staged in the index). When squashed by `git |
| 126 | rebase --autosquash`, it replaces the log message of _<commit>_ |
| 127 | without making any other changes. |
| 128 | + |
| 129 | Neither "fixup!" nor "amend!" commits change authorship of |
| 130 | _<commit>_ when applied by `git rebase --autosquash`. |
| 131 | See linkgit:git-rebase[1] for details. |
| 132 | |
| 133 | `--squash=<commit>`:: |
| 134 | Construct a commit message for use with `git rebase --autosquash`. |
| 135 | The commit message title is taken from the specified |
| 136 | commit with a prefix of "squash! ". Can be used with additional |
| 137 | commit message options (`-m`/`-c`/`-C`/`-F`). See |
| 138 | linkgit:git-rebase[1] for details. |
| 139 | |
| 140 | `--reset-author`:: |
| 141 | When used with `-C`/`-c`/`--amend` options, or when committing after a |
| 142 | conflicting cherry-pick, declare that the authorship of the |
| 143 | resulting commit now belongs to the committer. This also renews |
| 144 | the author timestamp. |
| 145 | |
| 146 | `--short`:: |
| 147 | When doing a dry-run, give the output in the short-format. See |
| 148 | linkgit:git-status[1] for details. Implies `--dry-run`. |
| 149 | |
| 150 | `--branch`:: |
| 151 | Show the branch and tracking info even in short-format. See |
| 152 | linkgit:git-status[1] for details. |
| 153 | |
| 154 | `--porcelain`:: |
| 155 | When doing a dry-run, give the output in a porcelain-ready |
| 156 | format. See linkgit:git-status[1] for details. Implies |
| 157 | `--dry-run`. |
| 158 | |
| 159 | `--long`:: |
| 160 | When doing a dry-run, give the output in the long-format. This |
| 161 | is the default output of linkgit:git-status[1]. Implies |
| 162 | `--dry-run`. |
| 163 | |
| 164 | `-z`:: |
| 165 | `--null`:: |
| 166 | When showing `short` or `porcelain` linkgit:git-status[1] output, print the |
| 167 | filename verbatim and terminate the entries with _NUL_, instead of _LF_. |
| 168 | If no format is given, implies the `--porcelain` output format. |
| 169 | Without the `-z` option, filenames with "unusual" characters are |
| 170 | quoted as explained for the configuration variable `core.quotePath` |
| 171 | (see linkgit:git-config[1]). |
| 172 | |
| 173 | `-F <file>`:: |
| 174 | `--file=<file>`:: |
| 175 | Take the commit message from _<file>_. Use '-' to |
| 176 | read the message from the standard input. |
| 177 | |
| 178 | `--author=<author>`:: |
| 179 | Override the commit author. Specify an explicit author using the |
| 180 | standard `A U Thor <author@example.com>` format. Otherwise _<author>_ |
| 181 | is assumed to be a pattern and is used to search for an existing |
| 182 | commit by that author (i.e. `git rev-list --all -i --author=<author>`); |
| 183 | the commit author is then copied from the first such commit found. |
| 184 | |
| 185 | `--date=<date>`:: |
| 186 | Override the author date used in the commit. |
| 187 | |
| 188 | `-m <msg>`:: |
| 189 | `--message=<msg>`:: |
| 190 | Use _<msg>_ as the commit message. |
| 191 | If multiple `-m` options are given, their values are |
| 192 | concatenated as separate paragraphs. |
| 193 | + |
| 194 | The `-m` option is mutually exclusive with `-c`, `-C`, and `-F`. |
| 195 | |
| 196 | `-t <file>`:: |
| 197 | `--template=<file>`:: |
| 198 | When editing the commit message, start the editor with the |
| 199 | contents in _<file>_. The `commit.template` configuration |
| 200 | variable is often used to give this option implicitly to the |
| 201 | command. This mechanism can be used by projects that want to |
| 202 | guide participants with some hints on what to write in the message |
| 203 | in what order. If the user exits the editor without editing the |
| 204 | message, the commit is aborted. This has no effect when a message |
| 205 | is given by other means, e.g. with the `-m` or `-F` options. |
| 206 | |
| 207 | include::signoff-option.adoc[] |
| 208 | |
| 209 | `--trailer <token>[(=|:)<value>]`:: |
| 210 | Specify a (_<token>_, _<value>_) pair that should be applied as a |
| 211 | trailer. (e.g. `git commit --trailer "Signed-off-by:C O Mitter \ |
| 212 | <committer@example.com>" --trailer "Helped-by:C O Mitter \ |
| 213 | <committer@example.com>"` will add the `Signed-off-by` trailer |
| 214 | and the `Helped-by` trailer to the commit message.) |
| 215 | The `trailer.*` configuration variables |
| 216 | (linkgit:git-interpret-trailers[1]) can be used to define if |
| 217 | a duplicated trailer is omitted, where in the run of trailers |
| 218 | each trailer would appear, and other details. |
| 219 | |
| 220 | `-n`:: |
| 221 | `--verify`:: |
| 222 | `--no-verify`:: |
| 223 | Bypass the `pre-commit` and `commit-msg` hooks. |
| 224 | See also linkgit:githooks[5]. |
| 225 | |
| 226 | `--allow-empty`:: |
| 227 | Usually recording a commit that has the exact same tree as its |
| 228 | sole parent commit is a mistake, and the command prevents you |
| 229 | from making such a commit. This option bypasses the safety, and |
| 230 | is primarily for use by foreign SCM interface scripts. |
| 231 | |
| 232 | `--allow-empty-message`:: |
| 233 | Create a commit with an empty commit message without using plumbing |
| 234 | commands like linkgit:git-commit-tree[1]. Like `--allow-empty`, this |
| 235 | command is primarily for use by foreign SCM interface scripts. |
| 236 | |
| 237 | `--cleanup=<mode>`:: |
| 238 | Determine how the supplied commit message should be |
| 239 | cleaned up before committing. The '<mode>' can be `strip`, |
| 240 | `whitespace`, `verbatim`, `scissors` or `default`. |
| 241 | + |
| 242 | -- |
| 243 | `strip`:: |
| 244 | Strip leading and trailing empty lines, trailing whitespace, |
| 245 | commentary and collapse consecutive empty lines. |
| 246 | `whitespace`:: |
| 247 | Same as `strip` except #commentary is not removed. |
| 248 | `verbatim`:: |
| 249 | Do not change the message at all. |
| 250 | `scissors`:: |
| 251 | Same as `whitespace` except that everything from (and including) |
| 252 | the line found below is truncated, if the message is to be edited. |
| 253 | "`#`" can be customized with `core.commentChar`. |
| 254 | |
| 255 | # ------------------------ >8 ------------------------ |
| 256 | |
| 257 | `default`:: |
| 258 | Same as `strip` if the message is to be edited. |
| 259 | Otherwise `whitespace`. |
| 260 | -- |
| 261 | + |
| 262 | The default can be changed by the `commit.cleanup` configuration |
| 263 | variable (see linkgit:git-config[1]). |
| 264 | |
| 265 | `-e`:: |
| 266 | `--edit`:: |
| 267 | Let the user further edit the message taken from _<file>_ |
| 268 | with `-F <file>`, command line with `-m <message>`, and |
| 269 | from _<commit>_ with `-C <commit>`. |
| 270 | |
| 271 | `--no-edit`:: |
| 272 | Use the selected commit message without launching an editor. |
| 273 | For example, `git commit --amend --no-edit` amends a commit |
| 274 | without changing its commit message. |
| 275 | |
| 276 | `--amend`:: |
| 277 | Replace the tip of the current branch by creating a new |
| 278 | commit. The recorded tree is prepared as usual (including |
| 279 | the effect of the `-i` and `-o` options and explicit |
| 280 | pathspec), and the message from the original commit is used |
| 281 | as the starting point, instead of an empty message, when no |
| 282 | other message is specified from the command line via options |
| 283 | such as `-m`, `-F`, `-c`, etc. The new commit has the same |
| 284 | parents and author as the current one (the `--reset-author` |
| 285 | option can countermand this). |
| 286 | + |
| 287 | -- |
| 288 | It is a rough equivalent for: |
| 289 | |
| 290 | ------ |
| 291 | $ git reset --soft HEAD^ |
| 292 | $ ... do something else to come up with the right tree ... |
| 293 | $ git commit -c ORIG_HEAD |
| 294 | |
| 295 | ------ |
| 296 | but can be used to amend a merge commit. |
| 297 | -- |
| 298 | + |
| 299 | You should understand the implications of rewriting history if you |
| 300 | amend a commit that has already been published. (See the "RECOVERING |
| 301 | FROM UPSTREAM REBASE" section in linkgit:git-rebase[1].) |
| 302 | |
| 303 | `--no-post-rewrite`:: |
| 304 | Bypass the `post-rewrite` hook. |
| 305 | |
| 306 | `-i`:: |
| 307 | `--include`:: |
| 308 | Before making a commit out of staged contents so far, |
| 309 | stage the contents of paths given on the command line |
| 310 | as well. This is usually not what you want unless you |
| 311 | are concluding a conflicted merge. |
| 312 | |
| 313 | `-o`:: |
| 314 | `--only`:: |
| 315 | Make a commit by taking the updated working tree contents |
| 316 | of the paths specified on the |
| 317 | command line, disregarding any contents that have been |
| 318 | staged for other paths. This is the default mode of operation of |
| 319 | `git commit` if any paths are given on the command line, |
| 320 | in which case this option can be omitted. |
| 321 | If this option is specified together with `--amend`, then |
| 322 | no paths need to be specified, which can be used to amend |
| 323 | the last commit without committing changes that have |
| 324 | already been staged. If used together with `--allow-empty` |
| 325 | paths are also not required, and an empty commit will be created. |
| 326 | |
| 327 | `--pathspec-from-file=<file>`:: |
| 328 | Pass pathspec in _<file>_ instead of commandline args. If |
| 329 | _<file>_ is exactly `-` then standard input is used. Pathspec |
| 330 | elements are separated by _LF_ or _CR_/_LF_. Pathspec elements can be |
| 331 | quoted as explained for the configuration variable `core.quotePath` |
| 332 | (see linkgit:git-config[1]). See also `--pathspec-file-nul` and |
| 333 | global `--literal-pathspecs`. |
| 334 | |
| 335 | `--pathspec-file-nul`:: |
| 336 | Only meaningful with `--pathspec-from-file`. Pathspec elements are |
| 337 | separated with _NUL_ character and all other characters are taken |
| 338 | literally (including newlines and quotes). |
| 339 | |
| 340 | `-u[<mode>]`:: |
| 341 | `--untracked-files[=<mode>]`:: |
| 342 | Show untracked files. |
| 343 | + |
| 344 | -- |
| 345 | The _<mode>_ parameter is optional (defaults to `all`), and is used to |
| 346 | specify the handling of untracked files; when `-u` is not used, the |
| 347 | default is `normal`, i.e. show untracked files and directories. |
| 348 | |
| 349 | The possible options are: |
| 350 | |
| 351 | `no`:: Show no untracked files |
| 352 | `normal`:: Shows untracked files and directories |
| 353 | `all`:: Also shows individual files in untracked directories. |
| 354 | |
| 355 | All usual spellings for Boolean value `true` are taken as `normal` |
| 356 | and `false` as `no`. |
| 357 | The default can be changed using the `status.showUntrackedFiles` |
| 358 | configuration variable documented in linkgit:git-config[1]. |
| 359 | -- |
| 360 | |
| 361 | `-v`:: |
| 362 | `--verbose`:: |
| 363 | Show unified diff between the `HEAD` commit and what |
| 364 | would be committed at the bottom of the commit message |
| 365 | template to help the user describe the commit by reminding |
| 366 | what changes the commit has. |
| 367 | Note that this diff output doesn't have its |
| 368 | lines prefixed with `#`. This diff will not be a part |
| 369 | of the commit message. See the `commit.verbose` configuration |
| 370 | variable in linkgit:git-config[1]. |
| 371 | + |
| 372 | If specified twice, show in addition the unified diff between |
| 373 | what would be committed and the worktree files, i.e. the unstaged |
| 374 | changes to tracked files. |
| 375 | |
| 376 | `-q`:: |
| 377 | `--quiet`:: |
| 378 | Suppress commit summary message. |
| 379 | |
| 380 | `--dry-run`:: |
| 381 | Do not create a commit, but show a list of paths that are |
| 382 | to be committed, paths with local changes that will be left |
| 383 | uncommitted and paths that are untracked. |
| 384 | |
| 385 | `--status`:: |
| 386 | Include the output of linkgit:git-status[1] in the commit |
| 387 | message template when using an editor to prepare the commit |
| 388 | message. Defaults to on, but can be used to override |
| 389 | configuration variable `commit.status`. |
| 390 | |
| 391 | `--no-status`:: |
| 392 | Do not include the output of linkgit:git-status[1] in the |
| 393 | commit message template when using an editor to prepare the |
| 394 | default commit message. |
| 395 | |
| 396 | `-S[<key-id>]`:: |
| 397 | `--gpg-sign[=<key-id>]`:: |
| 398 | `--no-gpg-sign`:: |
| 399 | GPG-sign commits. The _<key-id>_ is optional and |
| 400 | defaults to the committer identity; if specified, it must be |
| 401 | stuck to the option without a space. `--no-gpg-sign` is useful to |
| 402 | countermand both `commit.gpgSign` configuration variable, and |
| 403 | earlier `--gpg-sign`. |
| 404 | |
| 405 | `--`:: |
| 406 | Do not interpret any more arguments as options. |
| 407 | |
| 408 | `<pathspec>...`:: |
| 409 | When _<pathspec>_ is given on the command line, commit the contents of |
| 410 | the files that match the pathspec without recording the changes |
| 411 | already added to the index. The contents of these files are also |
| 412 | staged for the next commit on top of what have been staged before. |
| 413 | + |
| 414 | For more details, see the 'pathspec' entry in linkgit:gitglossary[7]. |
| 415 | |
| 416 | EXAMPLES |
| 417 | -------- |
| 418 | When recording your own work, the contents of modified files in |
| 419 | your working tree are temporarily stored to a staging area |
| 420 | called the "index" with `git add`. A file can be |
| 421 | reverted back, only in the index but not in the working tree, |
| 422 | to that of the last commit with `git restore --staged <file>`, |
| 423 | which effectively reverts `git add` and prevents the changes to |
| 424 | this file from participating in the next commit. After building |
| 425 | the state to be committed incrementally with these commands, |
| 426 | `git commit` (without any pathname parameter) is used to record what |
| 427 | has been staged so far. This is the most basic form of the |
| 428 | command. An example: |
| 429 | |
| 430 | ------------ |
| 431 | $ edit hello.c |
| 432 | $ git rm goodbye.c |
| 433 | $ git add hello.c |
| 434 | $ git commit |
| 435 | ------------ |
| 436 | |
| 437 | Instead of staging files after each individual change, you can |
| 438 | tell `git commit` to notice the changes to the files whose |
| 439 | contents are tracked in |
| 440 | your working tree and do corresponding `git add` and `git rm` |
| 441 | for you. That is, this example does the same as the earlier |
| 442 | example if there is no other change in your working tree: |
| 443 | |
| 444 | ------------ |
| 445 | $ edit hello.c |
| 446 | $ rm goodbye.c |
| 447 | $ git commit -a |
| 448 | ------------ |
| 449 | |
| 450 | The command `git commit -a` first looks at your working tree, |
| 451 | notices that you have modified `hello.c` and removed `goodbye.c`, |
| 452 | and performs necessary `git add` and `git rm` for you. |
| 453 | |
| 454 | After staging changes to many files, you can alter the order the |
| 455 | changes are recorded in, by giving pathnames to `git commit`. |
| 456 | When pathnames are given, the command makes a commit that |
| 457 | only records the changes made to the named paths: |
| 458 | |
| 459 | ------------ |
| 460 | $ edit hello.c hello.h |
| 461 | $ git add hello.c hello.h |
| 462 | $ edit Makefile |
| 463 | $ git commit Makefile |
| 464 | ------------ |
| 465 | |
| 466 | This makes a commit that records the modification to `Makefile`. |
| 467 | The changes staged for `hello.c` and `hello.h` are not included |
| 468 | in the resulting commit. However, their changes are not lost -- |
| 469 | they are still staged and merely held back. After the above |
| 470 | sequence, if you do: |
| 471 | |
| 472 | ------------ |
| 473 | $ git commit |
| 474 | ------------ |
| 475 | |
| 476 | this second commit would record the changes to `hello.c` and |
| 477 | `hello.h` as expected. |
| 478 | |
| 479 | After a merge (initiated by `git merge` or `git pull`) stops |
| 480 | because of conflicts, cleanly merged |
| 481 | paths are already staged to be committed for you, and paths that |
| 482 | conflicted are left in unmerged state. You would have to first |
| 483 | check which paths are conflicting with `git status` |
| 484 | and after fixing them manually in your working tree, you would |
| 485 | stage the result as usual with `git add`: |
| 486 | |
| 487 | ------------ |
| 488 | $ git status | grep unmerged |
| 489 | unmerged: hello.c |
| 490 | $ edit hello.c |
| 491 | $ git add hello.c |
| 492 | ------------ |
| 493 | |
| 494 | After resolving conflicts and staging the result, `git ls-files -u` |
| 495 | would stop mentioning the conflicted path. When you are done, |
| 496 | run `git commit` to finally record the merge: |
| 497 | |
| 498 | ------------ |
| 499 | $ git commit |
| 500 | ------------ |
| 501 | |
| 502 | As with the case to record your own changes, you can use `-a` |
| 503 | option to save typing. One difference is that during a merge |
| 504 | resolution, you cannot use `git commit` with pathnames to |
| 505 | alter the order the changes are committed, because the merge |
| 506 | should be recorded as a single commit. In fact, the command |
| 507 | refuses to run when given pathnames (but see `-i` option). |
| 508 | |
| 509 | COMMIT INFORMATION |
| 510 | ------------------ |
| 511 | |
| 512 | Author and committer information is taken from the following environment |
| 513 | variables, if set: |
| 514 | |
| 515 | * `GIT_AUTHOR_NAME` |
| 516 | * `GIT_AUTHOR_EMAIL` |
| 517 | * `GIT_AUTHOR_DATE` |
| 518 | * `GIT_COMMITTER_NAME` |
| 519 | * `GIT_COMMITTER_EMAIL` |
| 520 | * `GIT_COMMITTER_DATE` |
| 521 | |
| 522 | (nb "<", ">" and "\n"s are stripped) |
| 523 | |
| 524 | The author and committer names are by convention some form of a personal name |
| 525 | (that is, the name by which other humans refer to you), although Git does not |
| 526 | enforce or require any particular form. Arbitrary Unicode may be used, subject |
| 527 | to the constraints listed above. This name has no effect on authentication; for |
| 528 | that, see the `credential.username` variable in linkgit:git-config[1]. |
| 529 | |
| 530 | In case (some of) these environment variables are not set, the information |
| 531 | is taken from the configuration items `user.name` and `user.email`, or, if not |
| 532 | present, the environment variable `EMAIL`, or, if that is not set, |
| 533 | system user name and the hostname used for outgoing mail (taken |
| 534 | from `/etc/mailname` and falling back to the fully qualified hostname when |
| 535 | that file does not exist). |
| 536 | |
| 537 | The `author.name` and `committer.name` and their corresponding email options |
| 538 | override `user.name` and `user.email` if set and are overridden themselves by |
| 539 | the environment variables. |
| 540 | |
| 541 | The typical usage is to set just the `user.name` and `user.email` variables; |
| 542 | the other options are provided for more complex use cases. |
| 543 | |
| 544 | :git-commit: 1 |
| 545 | include::date-formats.adoc[] |
| 546 | |
| 547 | DISCUSSION |
| 548 | ---------- |
| 549 | |
| 550 | Though not required, it's a good idea to begin the commit message |
| 551 | with a single short (no more than 50 characters) line summarizing the |
| 552 | change, followed by a blank line and then a more thorough description. |
| 553 | The text up to the first blank line in a commit message is treated |
| 554 | as the commit title, and that title is used throughout Git. |
| 555 | For example, linkgit:git-format-patch[1] turns a commit into email, and it uses |
| 556 | the title on the Subject line and the rest of the commit in the body. |
| 557 | |
| 558 | include::i18n.adoc[] |
| 559 | |
| 560 | ENVIRONMENT AND CONFIGURATION VARIABLES |
| 561 | --------------------------------------- |
| 562 | The editor used to edit the commit log message will be chosen from the |
| 563 | `GIT_EDITOR` environment variable, the `core.editor` configuration variable, the |
| 564 | `VISUAL` environment variable, or the `EDITOR` environment variable (in that |
| 565 | order). See linkgit:git-var[1] for details. |
| 566 | |
| 567 | include::includes/cmd-config-section-rest.adoc[] |
| 568 | |
| 569 | include::config/commit.adoc[] |
| 570 | |
| 571 | HOOKS |
| 572 | ----- |
| 573 | This command can run `commit-msg`, `prepare-commit-msg`, `pre-commit`, |
| 574 | `post-commit` and `post-rewrite` hooks. See linkgit:githooks[5] for more |
| 575 | information. |
| 576 | |
| 577 | FILES |
| 578 | ----- |
| 579 | |
| 580 | `$GIT_DIR/COMMIT_EDITMSG`:: |
| 581 | This file contains the commit message of a commit in progress. |
| 582 | If `git commit` exits due to an error before creating a commit, |
| 583 | any commit message that has been provided by the user (e.g., in |
| 584 | an editor session) will be available in this file, but will be |
| 585 | overwritten by the next invocation of `git commit`. |
| 586 | |
| 587 | SEE ALSO |
| 588 | -------- |
| 589 | linkgit:git-add[1], |
| 590 | linkgit:git-rm[1], |
| 591 | linkgit:git-mv[1], |
| 592 | linkgit:git-merge[1], |
| 593 | linkgit:git-commit-tree[1] |
| 594 | |
| 595 | GIT |
| 596 | --- |
| 597 | Part of the linkgit:git[1] suite |