1git-commit(1) 2============= 3 4NAME 5---- 6git-commit - Record changes to the repository 7 8SYNOPSIS 9-------- 10[verse] 11'git commit' [-a | --interactive | --patch] [-s] [-v] [-u<mode>] [--amend] 12 [--dry-run] [(-c | -C | --fixup | --squash) <commit>] 13 [-F <file> | -m <msg>] [--reset-author] [--allow-empty] 14 [--allow-empty-message] [--no-verify] [-e] [--author=<author>] 15 [--date=<date>] [--cleanup=<mode>] [--status | --no-status] 16 [-i | -o] [-S[<keyid>]] [--] [<file>...] 17 18DESCRIPTION 19----------- 20Stores the current contents of the index in a new commit along 21with a log message from the user describing the changes. 22 23The content to be added can be specified in several ways: 24 251. by using 'git add' to incrementally "add" changes to the 26 index before using the 'commit' command (Note: even modified 27 files must be "added"); 28 292. by using 'git rm' to remove files from the working tree 30 and the index, again before using the 'commit' command; 31 323. by listing files as arguments to the 'commit' command, in which 33 case the commit will ignore changes staged in the index, and instead 34 record the current content of the listed files (which must already 35 be known to git); 36 374. by using the -a switch with the 'commit' command to automatically 38 "add" changes from all known files (i.e. all files that are already 39 listed in the index) and to automatically "rm" files in the index 40 that have been removed from the working tree, and then perform the 41 actual commit; 42 435. by using the --interactive or --patch switches with the 'commit' command 44 to decide one by one which files or hunks should be part of the commit, 45 before finalizing the operation. See the ``Interactive Mode'' section of 46 linkgit:git-add[1] to learn how to operate these modes. 47 48The `--dry-run` option can be used to obtain a 49summary of what is included by any of the above for the next 50commit by giving the same set of parameters (options and paths). 51 52If you make a commit and then find a mistake immediately after 53that, you can recover from it with 'git reset'. 54 55 56OPTIONS 57------- 58-a:: 59--all:: 60 Tell the command to automatically stage files that have 61 been modified and deleted, but new files you have not 62 told git about are not affected. 63 64-p:: 65--patch:: 66 Use the interactive patch selection interface to chose 67 which changes to commit. See linkgit:git-add[1] for 68 details. 69 70-C <commit>:: 71--reuse-message=<commit>:: 72 Take an existing commit object, and reuse the log message 73 and the authorship information (including the timestamp) 74 when creating the commit. 75 76-c <commit>:: 77--reedit-message=<commit>:: 78 Like '-C', but with '-c' the editor is invoked, so that 79 the user can further edit the commit message. 80 81--fixup=<commit>:: 82 Construct a commit message for use with `rebase --autosquash`. 83 The commit message will be the subject line from the specified 84 commit with a prefix of "fixup! ". See linkgit:git-rebase[1] 85 for details. 86 87--squash=<commit>:: 88 Construct a commit message for use with `rebase --autosquash`. 89 The commit message subject line is taken from the specified 90 commit with a prefix of "squash! ". Can be used with additional 91 commit message options (`-m`/`-c`/`-C`/`-F`). See 92 linkgit:git-rebase[1] for details. 93 94--reset-author:: 95 When used with -C/-c/--amend options, or when committing after a 96 a conflicting cherry-pick, declare that the authorship of the 97 resulting commit now belongs of the committer. This also renews 98 the author timestamp. 99 100--short:: 101 When doing a dry-run, give the output in the short-format. See 102 linkgit:git-status[1] for details. Implies `--dry-run`. 103 104--branch:: 105 Show the branch and tracking info even in short-format. 106 107--porcelain:: 108 When doing a dry-run, give the output in a porcelain-ready 109 format. See linkgit:git-status[1] for details. Implies 110 `--dry-run`. 111 112--long:: 113 When doing a dry-run, give the output in a the long-format. 114 Implies `--dry-run`. 115 116-z:: 117--null:: 118 When showing `short` or `porcelain` status output, terminate 119 entries in the status output with NUL, instead of LF. If no 120 format is given, implies the `--porcelain` output format. 121 122-F <file>:: 123--file=<file>:: 124 Take the commit message from the given file. Use '-' to 125 read the message from the standard input. 126 127--author=<author>:: 128 Override the commit author. Specify an explicit author using the 129 standard `A U Thor <author@example.com>` format. Otherwise <author> 130 is assumed to be a pattern and is used to search for an existing 131 commit by that author (i.e. rev-list --all -i --author=<author>); 132 the commit author is then copied from the first such commit found. 133 134--date=<date>:: 135 Override the author date used in the commit. 136 137-m <msg>:: 138--message=<msg>:: 139 Use the given <msg> as the commit message. 140 141-t <file>:: 142--template=<file>:: 143 When editing the commit message, start the editor with the 144 contents in the given file. The `commit.template` configuration 145 variable is often used to give this option implicitly to the 146 command. This mechanism can be used by projects that want to 147 guide participants with some hints on what to write in the message 148 in what order. If the user exits the editor without editing the 149 message, the commit is aborted. This has no effect when a message 150 is given by other means, e.g. with the `-m` or `-F` options. 151 152-s:: 153--signoff:: 154 Add Signed-off-by line by the committer at the end of the commit 155 log message. 156 157-n:: 158--no-verify:: 159 This option bypasses the pre-commit and commit-msg hooks. 160 See also linkgit:githooks[5]. 161 162--allow-empty:: 163 Usually recording a commit that has the exact same tree as its 164 sole parent commit is a mistake, and the command prevents you 165 from making such a commit. This option bypasses the safety, and 166 is primarily for use by foreign SCM interface scripts. 167 168--allow-empty-message:: 169 Like --allow-empty this command is primarily for use by foreign 170 SCM interface scripts. It allows you to create a commit with an 171 empty commit message without using plumbing commands like 172 linkgit:git-commit-tree[1]. 173 174--cleanup=<mode>:: 175 This option sets how the commit message is cleaned up. 176 The '<mode>' can be one of 'verbatim', 'whitespace', 'strip', 177 and 'default'. The 'default' mode will strip leading and 178 trailing empty lines and #commentary from the commit message 179 only if the message is to be edited. Otherwise only whitespace 180 removed. The 'verbatim' mode does not change message at all, 181 'whitespace' removes just leading/trailing whitespace lines 182 and 'strip' removes both whitespace and commentary. 183 184-e:: 185--edit:: 186 The message taken from file with `-F`, command line with 187 `-m`, and from file with `-C` are usually used as the 188 commit log message unmodified. This option lets you 189 further edit the message taken from these sources. 190 191--amend:: 192 Used to amend the tip of the current branch. Prepare the tree 193 object you would want to replace the latest commit as usual 194 (this includes the usual -i/-o and explicit paths), and the 195 commit log editor is seeded with the commit message from the 196 tip of the current branch. The commit you create replaces the 197 current tip -- if it was a merge, it will have the parents of 198 the current tip as parents -- so the current top commit is 199 discarded. 200+ 201-- 202It is a rough equivalent for: 203------ 204 $ git reset --soft HEAD^ 205 $ ... do something else to come up with the right tree ... 206 $ git commit -c ORIG_HEAD 207 208------ 209but can be used to amend a merge commit. 210-- 211+ 212You should understand the implications of rewriting history if you 213amend a commit that has already been published. (See the "RECOVERING 214FROM UPSTREAM REBASE" section in linkgit:git-rebase[1].) 215 216--no-post-rewrite:: 217 Bypass the post-rewrite hook. 218 219-i:: 220--include:: 221 Before making a commit out of staged contents so far, 222 stage the contents of paths given on the command line 223 as well. This is usually not what you want unless you 224 are concluding a conflicted merge. 225 226-o:: 227--only:: 228 Make a commit only from the paths specified on the 229 command line, disregarding any contents that have been 230 staged so far. This is the default mode of operation of 231 'git commit' if any paths are given on the command line, 232 in which case this option can be omitted. 233 If this option is specified together with '--amend', then 234 no paths need to be specified, which can be used to amend 235 the last commit without committing changes that have 236 already been staged. 237 238-u[<mode>]:: 239--untracked-files[=<mode>]:: 240 Show untracked files. 241+ 242The mode parameter is optional (defaults to 'all'), and is used to 243specify the handling of untracked files; when -u is not used, the 244default is 'normal', i.e. show untracked files and directories. 245+ 246The possible options are: 247+ 248 - 'no' - Show no untracked files 249 - 'normal' - Shows untracked files and directories 250 - 'all' - Also shows individual files in untracked directories. 251+ 252The default can be changed using the status.showUntrackedFiles 253configuration variable documented in linkgit:git-config[1]. 254 255-v:: 256--verbose:: 257 Show unified diff between the HEAD commit and what 258 would be committed at the bottom of the commit message 259 template. Note that this diff output doesn't have its 260 lines prefixed with '#'. 261 262-q:: 263--quiet:: 264 Suppress commit summary message. 265 266--dry-run:: 267 Do not create a commit, but show a list of paths that are 268 to be committed, paths with local changes that will be left 269 uncommitted and paths that are untracked. 270 271--status:: 272 Include the output of linkgit:git-status[1] in the commit 273 message template when using an editor to prepare the commit 274 message. Defaults to on, but can be used to override 275 configuration variable commit.status. 276 277--no-status:: 278 Do not include the output of linkgit:git-status[1] in the 279 commit message template when using an editor to prepare the 280 default commit message. 281 282-S[<keyid>]:: 283--gpg-sign[=<keyid>]:: 284 GPG-sign commit. 285 286\--:: 287 Do not interpret any more arguments as options. 288 289<file>...:: 290 When files are given on the command line, the command 291 commits the contents of the named files, without 292 recording the changes already staged. The contents of 293 these files are also staged for the next commit on top 294 of what have been staged before. 295 296:git-commit: 1 297include::date-formats.txt[] 298 299EXAMPLES 300-------- 301When recording your own work, the contents of modified files in 302your working tree are temporarily stored to a staging area 303called the "index" with 'git add'. A file can be 304reverted back, only in the index but not in the working tree, 305to that of the last commit with `git reset HEAD -- <file>`, 306which effectively reverts 'git add' and prevents the changes to 307this file from participating in the next commit. After building 308the state to be committed incrementally with these commands, 309`git commit` (without any pathname parameter) is used to record what 310has been staged so far. This is the most basic form of the 311command. An example: 312 313------------ 314$ edit hello.c 315$ git rm goodbye.c 316$ git add hello.c 317$ git commit 318------------ 319 320Instead of staging files after each individual change, you can 321tell `git commit` to notice the changes to the files whose 322contents are tracked in 323your working tree and do corresponding `git add` and `git rm` 324for you. That is, this example does the same as the earlier 325example if there is no other change in your working tree: 326 327------------ 328$ edit hello.c 329$ rm goodbye.c 330$ git commit -a 331------------ 332 333The command `git commit -a` first looks at your working tree, 334notices that you have modified hello.c and removed goodbye.c, 335and performs necessary `git add` and `git rm` for you. 336 337After staging changes to many files, you can alter the order the 338changes are recorded in, by giving pathnames to `git commit`. 339When pathnames are given, the command makes a commit that 340only records the changes made to the named paths: 341 342------------ 343$ edit hello.c hello.h 344$ git add hello.c hello.h 345$ edit Makefile 346$ git commit Makefile 347------------ 348 349This makes a commit that records the modification to `Makefile`. 350The changes staged for `hello.c` and `hello.h` are not included 351in the resulting commit. However, their changes are not lost -- 352they are still staged and merely held back. After the above 353sequence, if you do: 354 355------------ 356$ git commit 357------------ 358 359this second commit would record the changes to `hello.c` and 360`hello.h` as expected. 361 362After a merge (initiated by 'git merge' or 'git pull') stops 363because of conflicts, cleanly merged 364paths are already staged to be committed for you, and paths that 365conflicted are left in unmerged state. You would have to first 366check which paths are conflicting with 'git status' 367and after fixing them manually in your working tree, you would 368stage the result as usual with 'git add': 369 370------------ 371$ git status | grep unmerged 372unmerged: hello.c 373$ edit hello.c 374$ git add hello.c 375------------ 376 377After resolving conflicts and staging the result, `git ls-files -u` 378would stop mentioning the conflicted path. When you are done, 379run `git commit` to finally record the merge: 380 381------------ 382$ git commit 383------------ 384 385As with the case to record your own changes, you can use `-a` 386option to save typing. One difference is that during a merge 387resolution, you cannot use `git commit` with pathnames to 388alter the order the changes are committed, because the merge 389should be recorded as a single commit. In fact, the command 390refuses to run when given pathnames (but see `-i` option). 391 392 393DISCUSSION 394---------- 395 396Though not required, it's a good idea to begin the commit message 397with a single short (less than 50 character) line summarizing the 398change, followed by a blank line and then a more thorough description. 399The text up to the first blank line in a commit message is treated 400as the commit title, and that title is used throughout git. 401For example, linkgit:git-format-patch[1] turns a commit into email, and it uses 402the title on the Subject line and the rest of the commit in the body. 403 404include::i18n.txt[] 405 406ENVIRONMENT AND CONFIGURATION VARIABLES 407--------------------------------------- 408The editor used to edit the commit log message will be chosen from the 409GIT_EDITOR environment variable, the core.editor configuration variable, the 410VISUAL environment variable, or the EDITOR environment variable (in that 411order). See linkgit:git-var[1] for details. 412 413HOOKS 414----- 415This command can run `commit-msg`, `prepare-commit-msg`, `pre-commit`, 416and `post-commit` hooks. See linkgit:githooks[5] for more 417information. 418 419FILES 420----- 421 422`$GIT_DIR/COMMIT_EDITMSG`:: 423 This file contains the commit message of a commit in progress. 424 If `git commit` exits due to an error before creating a commit, 425 any commit message that has been provided by the user (e.g., in 426 an editor session) will be available in this file, but will be 427 overwritten by the next invocation of `git commit`. 428 429SEE ALSO 430-------- 431linkgit:git-add[1], 432linkgit:git-rm[1], 433linkgit:git-mv[1], 434linkgit:git-merge[1], 435linkgit:git-commit-tree[1] 436 437GIT 438--- 439Part of the linkgit:git[1] suite