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