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