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