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