1GIT-COMMIT(1) Git Manual GIT-COMMIT(1)
2
6 git-commit - Record changes to the repository
7
9 git commit [-a | --interactive | --patch] [-s] [-v] [-u<mode>] [--amend]
10 [--dry-run] [(-c | -C | --squash) <commit> | --fixup [(amend|reword):]<commit>)]
11 [-F <file> | -m <msg>] [--reset-author] [--allow-empty]
12 [--allow-empty-message] [--no-verify] [-e] [--author=<author>]
13 [--date=<date>] [--cleanup=<mode>] [--[no-]status]
14 [-i | -o] [--pathspec-from-file=<file> [--pathspec-file-nul]]
15 [(--trailer <token>[(=|:)<value>])...] [-S[<keyid>]]
16 [--] [<pathspec>...]
17
19 Create a new commit containing the current contents of the index and
20 the given log message describing the changes. The new commit is a
21 direct child of HEAD, usually the tip of the current branch, and the
22 branch is updated to point to it (unless no branch is associated with
23 the working tree, in which case HEAD is "detached" as described in git-
24 checkout(1)).
25 The content to be committed can be specified in several ways:
27 1. by using git-add(1) to incrementally "add" changes to the index
29 before using the commit command (Note: even modified files must be
30 "added");
31 2. by using git-rm(1) to remove files from the working tree and the
33 index, again before using the commit command;
34 3. by listing files as arguments to the commit command (without
36 --interactive or --patch switch), in which case the commit will
37 ignore changes staged in the index, and instead record the current
38 content of the listed files (which must already be known to Git);
39 4. by using the -a switch with the commit command to automatically
41 "add" changes from all known files (i.e. all files that are already
42 listed in the index) and to automatically "rm" files in the index
43 that have been removed from the working tree, and then perform the
44 actual commit;
45 5. by using the --interactive or --patch switches with the commit
47 command to decide one by one which files or hunks should be part of
48 the commit in addition to contents in the index, before finalizing
49 the operation. See the “Interactive Mode” section of git-add(1) to
50 learn how to operate these modes.
51 The --dry-run option can be used to obtain a summary of what is
53 included by any of the above for the next commit by giving the same set
54 of parameters (options and paths).
55 If you make a commit and then find a mistake immediately after that,
57 you can recover from it with git reset.
58
60 -a, --all
61 Tell the command to automatically stage files that have been
62 modified and deleted, but new files you have not told Git about are
63 not affected.
64 -p, --patch
66 Use the interactive patch selection interface to choose which
67 changes to commit. See git-add(1) for details.
68 -C <commit>, --reuse-message=<commit>
70 Take an existing commit object, and reuse the log message and the
71 authorship information (including the timestamp) when creating the
72 commit.
73 -c <commit>, --reedit-message=<commit>
75 Like -C, but with -c the editor is invoked, so that the user can
76 further edit the commit message.
77 --fixup=[(amend|reword):]<commit>
79 Create a new commit which "fixes up" <commit> when applied with git
80 rebase --autosquash. Plain --fixup=<commit> creates a "fixup!"
81 commit which changes the content of <commit> but leaves its log
82 message untouched. --fixup=amend:<commit> is similar but creates
83 an "amend!" commit which also replaces the log message of <commit>
84 with the log message of the "amend!" commit.
85 --fixup=reword:<commit> creates an "amend!" commit which replaces
86 the log message of <commit> with its own log message but makes no
87 changes to the content of <commit>.
88 The commit created by plain --fixup=<commit> has a subject composed
90 of "fixup!" followed by the subject line from <commit>, and is
91 recognized specially by git rebase --autosquash. The -m option may
92 be used to supplement the log message of the created commit, but
93 the additional commentary will be thrown away once the "fixup!"
94 commit is squashed into <commit> by git rebase --autosquash.
95 The commit created by --fixup=amend:<commit> is similar but its
97 subject is instead prefixed with "amend!". The log message of
98 <commit> is copied into the log message of the "amend!" commit and
99 opened in an editor so it can be refined. When git rebase
100 --autosquash squashes the "amend!" commit into <commit>, the log
101 message of <commit> is replaced by the refined log message from the
102 "amend!" commit. It is an error for the "amend!" commit’s log
103 message to be empty unless --allow-empty-message is specified.
104 --fixup=reword:<commit> is shorthand for --fixup=amend:<commit>
106 --only. It creates an "amend!" commit with only a log message
107 (ignoring any changes staged in the index). When squashed by git
108 rebase --autosquash, it replaces the log message of <commit>
109 without making any other changes.
110 Neither "fixup!" nor "amend!" commits change authorship of <commit>
112 when applied by git rebase --autosquash. See git-rebase(1) for
113 details.
114 --squash=<commit>
116 Construct a commit message for use with rebase --autosquash. The
117 commit message subject line is taken from the specified commit with
118 a prefix of "squash! ". Can be used with additional commit message
119 options (-m/-c/-C/-F). See git-rebase(1) for details.
120 --reset-author
122 When used with -C/-c/--amend options, or when committing after a
123 conflicting cherry-pick, declare that the authorship of the
124 resulting commit now belongs to the committer. This also renews the
125 author timestamp.
126 --short
128 When doing a dry-run, give the output in the short-format. See git-
129 status(1) for details. Implies --dry-run.
130 --branch
132 Show the branch and tracking info even in short-format.
133 --porcelain
135 When doing a dry-run, give the output in a porcelain-ready format.
136 See git-status(1) for details. Implies --dry-run.
137 --long
139 When doing a dry-run, give the output in the long-format. Implies
140 --dry-run.
141 -z, --null
143 When showing short or porcelain status output, print the filename
144 verbatim and terminate the entries with NUL, instead of LF. If no
145 format is given, implies the --porcelain output format. Without the
146 -z option, filenames with "unusual" characters are quoted as
147 explained for the configuration variable core.quotePath (see git-
148 config(1)).
149 -F <file>, --file=<file>
151 Take the commit message from the given file. Use - to read the
152 message from the standard input.
153 --author=<author>
155 Override the commit author. Specify an explicit author using the
156 standard A U Thor <author@example.com> format. Otherwise <author>
157 is assumed to be a pattern and is used to search for an existing
158 commit by that author (i.e. rev-list --all -i --author=<author>);
159 the commit author is then copied from the first such commit found.
160 --date=<date>
162 Override the author date used in the commit.
163 -m <msg>, --message=<msg>
165 Use the given <msg> as the commit message. If multiple -m options
166 are given, their values are concatenated as separate paragraphs.
167 The -m option is mutually exclusive with -c, -C, and -F.
169 -t <file>, --template=<file>
171 When editing the commit message, start the editor with the contents
172 in the given file. The commit.template configuration variable is
173 often used to give this option implicitly to the command. This
174 mechanism can be used by projects that want to guide participants
175 with some hints on what to write in the message in what order. If
176 the user exits the editor without editing the message, the commit
177 is aborted. This has no effect when a message is given by other
178 means, e.g. with the -m or -F options.
179 -s, --signoff, --no-signoff
181 Add a Signed-off-by trailer by the committer at the end of the
182 commit log message. The meaning of a signoff depends on the project
183 to which you’re committing. For example, it may certify that the
184 committer has the rights to submit the work under the project’s
185 license or agrees to some contributor representation, such as a
186 Developer Certificate of Origin. (See
187 http://developercertificate.org for the one used by the Linux
188 kernel and Git projects.) Consult the documentation or leadership
189 of the project to which you’re contributing to understand how the
190 signoffs are used in that project.
191 The --no-signoff option can be used to countermand an earlier
193 --signoff option on the command line.
194 --trailer <token>[(=|:)<value>]
196 Specify a (<token>, <value>) pair that should be applied as a
197 trailer. (e.g. git commit --trailer "Signed-off-by:C O Mitter \
198 <committer@example.com>" --trailer "Helped-by:C O Mitter \
199 <committer@example.com>" will add the "Signed-off-by" trailer and
200 the "Helped-by" trailer to the commit message.) The trailer.*
201 configuration variables (git-interpret-trailers(1)) can be used to
202 define if a duplicated trailer is omitted, where in the run of
203 trailers each trailer would appear, and other details.
204 -n, --no-verify
206 This option bypasses the pre-commit and commit-msg hooks. See also
207 githooks(5).
208 --allow-empty
210 Usually recording a commit that has the exact same tree as its sole
211 parent commit is a mistake, and the command prevents you from
212 making such a commit. This option bypasses the safety, and is
213 primarily for use by foreign SCM interface scripts.
214 --allow-empty-message
216 Like --allow-empty this command is primarily for use by foreign SCM
217 interface scripts. It allows you to create a commit with an empty
218 commit message without using plumbing commands like git-commit-
219 tree(1).
220 --cleanup=<mode>
222 This option determines how the supplied commit message should be
223 cleaned up before committing. The <mode> can be strip, whitespace,
224 verbatim, scissors or default.
225 strip
227 Strip leading and trailing empty lines, trailing whitespace,
228 commentary and collapse consecutive empty lines.
229 whitespace
231 Same as strip except #commentary is not removed.
232 verbatim
234 Do not change the message at all.
235 scissors
237 Same as whitespace except that everything from (and including)
238 the line found below is truncated, if the message is to be
239 edited. "#" can be customized with core.commentChar.
240 # ------------------------ >8 ------------------------
242 default
244 Same as strip if the message is to be edited. Otherwise
245 whitespace.
246 The default can be changed by the commit.cleanup configuration
248 variable (see git-config(1)).
249 -e, --edit
251 The message taken from file with -F, command line with -m, and from
252 commit object with -C are usually used as the commit log message
253 unmodified. This option lets you further edit the message taken
254 from these sources.
255 --no-edit
257 Use the selected commit message without launching an editor. For
258 example, git commit --amend --no-edit amends a commit without
259 changing its commit message.
260 --amend
262 Replace the tip of the current branch by creating a new commit. The
263 recorded tree is prepared as usual (including the effect of the -i
264 and -o options and explicit pathspec), and the message from the
265 original commit is used as the starting point, instead of an empty
266 message, when no other message is specified from the command line
267 via options such as -m, -F, -c, etc. The new commit has the same
268 parents and author as the current one (the --reset-author option
269 can countermand this).
270 It is a rough equivalent for:
272 $ git reset --soft HEAD^
274 $ ... do something else to come up with the right tree ...
275 $ git commit -c ORIG_HEAD
276 but can be used to amend a merge commit.
278 You should understand the implications of rewriting history if you
280 amend a commit that has already been published. (See the
281 "RECOVERING FROM UPSTREAM REBASE" section in git-rebase(1).)
282 --no-post-rewrite
284 Bypass the post-rewrite hook.
285 -i, --include
287 Before making a commit out of staged contents so far, stage the
288 contents of paths given on the command line as well. This is
289 usually not what you want unless you are concluding a conflicted
290 merge.
291 -o, --only
293 Make a commit by taking the updated working tree contents of the
294 paths specified on the command line, disregarding any contents that
295 have been staged for other paths. This is the default mode of
296 operation of git commit if any paths are given on the command line,
297 in which case this option can be omitted. If this option is
298 specified together with --amend, then no paths need to be
299 specified, which can be used to amend the last commit without
300 committing changes that have already been staged. If used together
301 with --allow-empty paths are also not required, and an empty commit
302 will be created.
303 --pathspec-from-file=<file>
305 Pathspec is passed in <file> instead of commandline args. If <file>
306 is exactly - then standard input is used. Pathspec elements are
307 separated by LF or CR/LF. Pathspec elements can be quoted as
308 explained for the configuration variable core.quotePath (see git-
309 config(1)). See also --pathspec-file-nul and global
310 --literal-pathspecs.
311 --pathspec-file-nul
313 Only meaningful with --pathspec-from-file. Pathspec elements are
314 separated with NUL character and all other characters are taken
315 literally (including newlines and quotes).
316 -u[<mode>], --untracked-files[=<mode>]
318 Show untracked files.
319 The mode parameter is optional (defaults to all), and is used to
321 specify the handling of untracked files; when -u is not used, the
322 default is normal, i.e. show untracked files and directories.
323 The possible options are:
325 • no - Show no untracked files
327 • normal - Shows untracked files and directories
329 • all - Also shows individual files in untracked directories.
331 The default can be changed using the status.showUntrackedFiles
333 configuration variable documented in git-config(1).
334 -v, --verbose
336 Show unified diff between the HEAD commit and what would be
337 committed at the bottom of the commit message template to help the
338 user describe the commit by reminding what changes the commit has.
339 Note that this diff output doesn’t have its lines prefixed with #.
340 This diff will not be a part of the commit message. See the
341 commit.verbose configuration variable in git-config(1).
342 If specified twice, show in addition the unified diff between what
344 would be committed and the worktree files, i.e. the unstaged
345 changes to tracked files.
346 -q, --quiet
348 Suppress commit summary message.
349 --dry-run
351 Do not create a commit, but show a list of paths that are to be
352 committed, paths with local changes that will be left uncommitted
353 and paths that are untracked.
354 --status
356 Include the output of git-status(1) in the commit message template
357 when using an editor to prepare the commit message. Defaults to on,
358 but can be used to override configuration variable commit.status.
359 --no-status
361 Do not include the output of git-status(1) in the commit message
362 template when using an editor to prepare the default commit
363 message.
364 -S[<keyid>], --gpg-sign[=<keyid>], --no-gpg-sign
366 GPG-sign commits. The keyid argument is optional and defaults to
367 the committer identity; if specified, it must be stuck to the
368 option without a space. --no-gpg-sign is useful to countermand
369 both commit.gpgSign configuration variable, and earlier --gpg-sign.
370 --
372 Do not interpret any more arguments as options.
373 <pathspec>...
375 When pathspec is given on the command line, commit the contents of
376 the files that match the pathspec without recording the changes
377 already added to the index. The contents of these files are also
378 staged for the next commit on top of what have been staged before.
379 For more details, see the pathspec entry in gitglossary(7).
381
383 When recording your own work, the contents of modified files in your
384 working tree are temporarily stored to a staging area called the
385 "index" with git add. A file can be reverted back, only in the index
386 but not in the working tree, to that of the last commit with git
387 restore --staged <file>, which effectively reverts git add and prevents
388 the changes to this file from participating in the next commit. After
389 building the state to be committed incrementally with these commands,
390 git commit (without any pathname parameter) is used to record what has
391 been staged so far. This is the most basic form of the command. An
392 example:
393 $ edit hello.c
395 $ git rm goodbye.c
396 $ git add hello.c
397 $ git commit
398 Instead of staging files after each individual change, you can tell git
400 commit to notice the changes to the files whose contents are tracked in
401 your working tree and do corresponding git add and git rm for you. That
402 is, this example does the same as the earlier example if there is no
403 other change in your working tree:
404 $ edit hello.c
406 $ rm goodbye.c
407 $ git commit -a
408 The command git commit -a first looks at your working tree, notices
410 that you have modified hello.c and removed goodbye.c, and performs
411 necessary git add and git rm for you.
412 After staging changes to many files, you can alter the order the
414 changes are recorded in, by giving pathnames to git commit. When
415 pathnames are given, the command makes a commit that only records the
416 changes made to the named paths:
417 $ edit hello.c hello.h
419 $ git add hello.c hello.h
420 $ edit Makefile
421 $ git commit Makefile
422 This makes a commit that records the modification to Makefile. The
424 changes staged for hello.c and hello.h are not included in the
425 resulting commit. However, their changes are not lost — they are still
426 staged and merely held back. After the above sequence, if you do:
427 $ git commit
429 this second commit would record the changes to hello.c and hello.h as
431 expected.
432 After a merge (initiated by git merge or git pull) stops because of
434 conflicts, cleanly merged paths are already staged to be committed for
435 you, and paths that conflicted are left in unmerged state. You would
436 have to first check which paths are conflicting with git status and
437 after fixing them manually in your working tree, you would stage the
438 result as usual with git add:
439 $ git status | grep unmerged
441 unmerged: hello.c
442 $ edit hello.c
443 $ git add hello.c
444 After resolving conflicts and staging the result, git ls-files -u would
446 stop mentioning the conflicted path. When you are done, run git commit
447 to finally record the merge:
448 $ git commit
450 As with the case to record your own changes, you can use -a option to
452 save typing. One difference is that during a merge resolution, you
453 cannot use git commit with pathnames to alter the order the changes are
454 committed, because the merge should be recorded as a single commit. In
455 fact, the command refuses to run when given pathnames (but see -i
456 option).
457
459 Author and committer information is taken from the following
460 environment variables, if set:
461 GIT_AUTHOR_NAME
463 GIT_AUTHOR_EMAIL
464 GIT_AUTHOR_DATE
465 GIT_COMMITTER_NAME
466 GIT_COMMITTER_EMAIL
467 GIT_COMMITTER_DATE
468 (nb "<", ">" and "\n"s are stripped)
470 The author and committer names are by convention some form of a
472 personal name (that is, the name by which other humans refer to you),
473 although Git does not enforce or require any particular form. Arbitrary
474 Unicode may be used, subject to the constraints listed above. This name
475 has no effect on authentication; for that, see the credential.username
476 variable in git-config(1).
477 In case (some of) these environment variables are not set, the
479 information is taken from the configuration items user.name and
480 user.email, or, if not present, the environment variable EMAIL, or, if
481 that is not set, system user name and the hostname used for outgoing
482 mail (taken from /etc/mailname and falling back to the fully qualified
483 hostname when that file does not exist).
484 The author.name and committer.name and their corresponding email
486 options override user.name and user.email if set and are overridden
487 themselves by the environment variables.
488 The typical usage is to set just the user.name and user.email
490 variables; the other options are provided for more complex use cases.
491
493 The GIT_AUTHOR_DATE and GIT_COMMITTER_DATE environment variables
494 support the following date formats:
495 Git internal format
497 It is <unix timestamp> <time zone offset>, where <unix timestamp>
498 is the number of seconds since the UNIX epoch. <time zone offset>
499 is a positive or negative offset from UTC. For example CET (which
500 is 1 hour ahead of UTC) is +0100.
501 RFC 2822
503 The standard email format as described by RFC 2822, for example
504 Thu, 07 Apr 2005 22:13:13 +0200.
505 ISO 8601
507 Time and date specified by the ISO 8601 standard, for example
508 2005-04-07T22:13:13. The parser accepts a space instead of the T
509 character as well. Fractional parts of a second will be ignored,
510 for example 2005-04-07T22:13:13.019 will be treated as
511 2005-04-07T22:13:13.
512 Note
514 In addition, the date part is accepted in the following
515 formats: YYYY.MM.DD, MM/DD/YYYY and DD.MM.YYYY.
516 In addition to recognizing all date formats above, the --date option
518 will also try to make sense of other, more human-centric date formats,
519 such as relative dates like "yesterday" or "last Friday at noon".
520
522 Though not required, it’s a good idea to begin the commit message with
523 a single short (less than 50 character) line summarizing the change,
524 followed by a blank line and then a more thorough description. The text
525 up to the first blank line in a commit message is treated as the commit
526 title, and that title is used throughout Git. For example, git-format-
527 patch(1) turns a commit into email, and it uses the title on the
528 Subject line and the rest of the commit in the body.
529 Git is to some extent character encoding agnostic.
531 • The contents of the blob objects are uninterpreted sequences of
533 bytes. There is no encoding translation at the core level.
534 • Path names are encoded in UTF-8 normalization form C. This applies
536 to tree objects, the index file, ref names, as well as path names
537 in command line arguments, environment variables and config files
538 (.git/config (see git-config(1)), gitignore(5), gitattributes(5)
539 and gitmodules(5)).
540 Note that Git at the core level treats path names simply as
542 sequences of non-NUL bytes, there are no path name encoding
543 conversions (except on Mac and Windows). Therefore, using non-ASCII
544 path names will mostly work even on platforms and file systems that
545 use legacy extended ASCII encodings. However, repositories created
546 on such systems will not work properly on UTF-8-based systems (e.g.
547 Linux, Mac, Windows) and vice versa. Additionally, many Git-based
548 tools simply assume path names to be UTF-8 and will fail to display
549 other encodings correctly.
550 • Commit log messages are typically encoded in UTF-8, but other
552 extended ASCII encodings are also supported. This includes
553 ISO-8859-x, CP125x and many others, but not UTF-16/32, EBCDIC and
554 CJK multi-byte encodings (GBK, Shift-JIS, Big5, EUC-x, CP9xx etc.).
555 Although we encourage that the commit log messages are encoded in
557 UTF-8, both the core and Git Porcelain are designed not to force UTF-8
558 on projects. If all participants of a particular project find it more
559 convenient to use legacy encodings, Git does not forbid it. However,
560 there are a few things to keep in mind.
561 1. git commit and git commit-tree issues a warning if the commit log
563 message given to it does not look like a valid UTF-8 string, unless
564 you explicitly say your project uses a legacy encoding. The way to
565 say this is to have i18n.commitEncoding in .git/config file, like
566 this:
567 [i18n]
569 commitEncoding = ISO-8859-1
570 Commit objects created with the above setting record the value of
572 i18n.commitEncoding in its encoding header. This is to help other
573 people who look at them later. Lack of this header implies that the
574 commit log message is encoded in UTF-8.
575 2. git log, git show, git blame and friends look at the encoding
577 header of a commit object, and try to re-code the log message into
578 UTF-8 unless otherwise specified. You can specify the desired
579 output encoding with i18n.logOutputEncoding in .git/config file,
580 like this:
581 [i18n]
583 logOutputEncoding = ISO-8859-1
584 If you do not have this configuration variable, the value of
586 i18n.commitEncoding is used instead.
587 Note that we deliberately chose not to re-code the commit log message
589 when a commit is made to force UTF-8 at the commit object level,
590 because re-coding to UTF-8 is not necessarily a reversible operation.
591
593 The editor used to edit the commit log message will be chosen from the
594 GIT_EDITOR environment variable, the core.editor configuration
595 variable, the VISUAL environment variable, or the EDITOR environment
596 variable (in that order). See git-var(1) for details.
597
599 This command can run commit-msg, prepare-commit-msg, pre-commit,
600 post-commit and post-rewrite hooks. See githooks(5) for more
601 information.
602
604 $GIT_DIR/COMMIT_EDITMSG
605 This file contains the commit message of a commit in progress. If
606 git commit exits due to an error before creating a commit, any
607 commit message that has been provided by the user (e.g., in an
608 editor session) will be available in this file, but will be
609 overwritten by the next invocation of git commit.
610
612 git-add(1), git-rm(1), git-mv(1), git-merge(1), git-commit-tree(1)
613
615 Part of the git(1) suite
616Git 2.33.1 2021-10-12 GIT-COMMIT(1)