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 By default, the pre-commit and commit-msg hooks are run. When any
207 of --no-verify or -n is given, these are bypassed. See also
208 githooks(5).
209 --allow-empty
211 Usually recording a commit that has the exact same tree as its sole
212 parent commit is a mistake, and the command prevents you from
213 making such a commit. This option bypasses the safety, and is
214 primarily for use by foreign SCM interface scripts.
215 --allow-empty-message
217 Like --allow-empty this command is primarily for use by foreign SCM
218 interface scripts. It allows you to create a commit with an empty
219 commit message without using plumbing commands like git-commit-
220 tree(1).
221 --cleanup=<mode>
223 This option determines how the supplied commit message should be
224 cleaned up before committing. The <mode> can be strip, whitespace,
225 verbatim, scissors or default.
226 strip
228 Strip leading and trailing empty lines, trailing whitespace,
229 commentary and collapse consecutive empty lines.
230 whitespace
232 Same as strip except #commentary is not removed.
233 verbatim
235 Do not change the message at all.
236 scissors
238 Same as whitespace except that everything from (and including)
239 the line found below is truncated, if the message is to be
240 edited. "#" can be customized with core.commentChar.
241 # ------------------------ >8 ------------------------
243 default
245 Same as strip if the message is to be edited. Otherwise
246 whitespace.
247 The default can be changed by the commit.cleanup configuration
249 variable (see git-config(1)).
250 -e, --edit
252 The message taken from file with -F, command line with -m, and from
253 commit object with -C are usually used as the commit log message
254 unmodified. This option lets you further edit the message taken
255 from these sources.
256 --no-edit
258 Use the selected commit message without launching an editor. For
259 example, git commit --amend --no-edit amends a commit without
260 changing its commit message.
261 --amend
263 Replace the tip of the current branch by creating a new commit. The
264 recorded tree is prepared as usual (including the effect of the -i
265 and -o options and explicit pathspec), and the message from the
266 original commit is used as the starting point, instead of an empty
267 message, when no other message is specified from the command line
268 via options such as -m, -F, -c, etc. The new commit has the same
269 parents and author as the current one (the --reset-author option
270 can countermand this).
271 It is a rough equivalent for:
273 $ git reset --soft HEAD^
275 $ ... do something else to come up with the right tree ...
276 $ git commit -c ORIG_HEAD
277 but can be used to amend a merge commit.
279 You should understand the implications of rewriting history if you
281 amend a commit that has already been published. (See the
282 "RECOVERING FROM UPSTREAM REBASE" section in git-rebase(1).)
283 --no-post-rewrite
285 Bypass the post-rewrite hook.
286 -i, --include
288 Before making a commit out of staged contents so far, stage the
289 contents of paths given on the command line as well. This is
290 usually not what you want unless you are concluding a conflicted
291 merge.
292 -o, --only
294 Make a commit by taking the updated working tree contents of the
295 paths specified on the command line, disregarding any contents that
296 have been staged for other paths. This is the default mode of
297 operation of git commit if any paths are given on the command line,
298 in which case this option can be omitted. If this option is
299 specified together with --amend, then no paths need to be
300 specified, which can be used to amend the last commit without
301 committing changes that have already been staged. If used together
302 with --allow-empty paths are also not required, and an empty commit
303 will be created.
304 --pathspec-from-file=<file>
306 Pathspec is passed in <file> instead of commandline args. If <file>
307 is exactly - then standard input is used. Pathspec elements are
308 separated by LF or CR/LF. Pathspec elements can be quoted as
309 explained for the configuration variable core.quotePath (see git-
310 config(1)). See also --pathspec-file-nul and global
311 --literal-pathspecs.
312 --pathspec-file-nul
314 Only meaningful with --pathspec-from-file. Pathspec elements are
315 separated with NUL character and all other characters are taken
316 literally (including newlines and quotes).
317 -u[<mode>], --untracked-files[=<mode>]
319 Show untracked files.
320 The mode parameter is optional (defaults to all), and is used to
322 specify the handling of untracked files; when -u is not used, the
323 default is normal, i.e. show untracked files and directories.
324 The possible options are:
326 • no - Show no untracked files
328 • normal - Shows untracked files and directories
330 • all - Also shows individual files in untracked directories.
332 The default can be changed using the status.showUntrackedFiles
334 configuration variable documented in git-config(1).
335 -v, --verbose
337 Show unified diff between the HEAD commit and what would be
338 committed at the bottom of the commit message template to help the
339 user describe the commit by reminding what changes the commit has.
340 Note that this diff output doesn’t have its lines prefixed with #.
341 This diff will not be a part of the commit message. See the
342 commit.verbose configuration variable in git-config(1).
343 If specified twice, show in addition the unified diff between what
345 would be committed and the worktree files, i.e. the unstaged
346 changes to tracked files.
347 -q, --quiet
349 Suppress commit summary message.
350 --dry-run
352 Do not create a commit, but show a list of paths that are to be
353 committed, paths with local changes that will be left uncommitted
354 and paths that are untracked.
355 --status
357 Include the output of git-status(1) in the commit message template
358 when using an editor to prepare the commit message. Defaults to on,
359 but can be used to override configuration variable commit.status.
360 --no-status
362 Do not include the output of git-status(1) in the commit message
363 template when using an editor to prepare the default commit
364 message.
365 -S[<keyid>], --gpg-sign[=<keyid>], --no-gpg-sign
367 GPG-sign commits. The keyid argument is optional and defaults to
368 the committer identity; if specified, it must be stuck to the
369 option without a space. --no-gpg-sign is useful to countermand
370 both commit.gpgSign configuration variable, and earlier --gpg-sign.
371 --
373 Do not interpret any more arguments as options.
374 <pathspec>...
376 When pathspec is given on the command line, commit the contents of
377 the files that match the pathspec without recording the changes
378 already added to the index. The contents of these files are also
379 staged for the next commit on top of what have been staged before.
380 For more details, see the pathspec entry in gitglossary(7).
382
384 When recording your own work, the contents of modified files in your
385 working tree are temporarily stored to a staging area called the
386 "index" with git add. A file can be reverted back, only in the index
387 but not in the working tree, to that of the last commit with git
388 restore --staged <file>, which effectively reverts git add and prevents
389 the changes to this file from participating in the next commit. After
390 building the state to be committed incrementally with these commands,
391 git commit (without any pathname parameter) is used to record what has
392 been staged so far. This is the most basic form of the command. An
393 example:
394 $ edit hello.c
396 $ git rm goodbye.c
397 $ git add hello.c
398 $ git commit
399 Instead of staging files after each individual change, you can tell git
401 commit to notice the changes to the files whose contents are tracked in
402 your working tree and do corresponding git add and git rm for you. That
403 is, this example does the same as the earlier example if there is no
404 other change in your working tree:
405 $ edit hello.c
407 $ rm goodbye.c
408 $ git commit -a
409 The command git commit -a first looks at your working tree, notices
411 that you have modified hello.c and removed goodbye.c, and performs
412 necessary git add and git rm for you.
413 After staging changes to many files, you can alter the order the
415 changes are recorded in, by giving pathnames to git commit. When
416 pathnames are given, the command makes a commit that only records the
417 changes made to the named paths:
418 $ edit hello.c hello.h
420 $ git add hello.c hello.h
421 $ edit Makefile
422 $ git commit Makefile
423 This makes a commit that records the modification to Makefile. The
425 changes staged for hello.c and hello.h are not included in the
426 resulting commit. However, their changes are not lost — they are still
427 staged and merely held back. After the above sequence, if you do:
428 $ git commit
430 this second commit would record the changes to hello.c and hello.h as
432 expected.
433 After a merge (initiated by git merge or git pull) stops because of
435 conflicts, cleanly merged paths are already staged to be committed for
436 you, and paths that conflicted are left in unmerged state. You would
437 have to first check which paths are conflicting with git status and
438 after fixing them manually in your working tree, you would stage the
439 result as usual with git add:
440 $ git status | grep unmerged
442 unmerged: hello.c
443 $ edit hello.c
444 $ git add hello.c
445 After resolving conflicts and staging the result, git ls-files -u would
447 stop mentioning the conflicted path. When you are done, run git commit
448 to finally record the merge:
449 $ git commit
451 As with the case to record your own changes, you can use -a option to
453 save typing. One difference is that during a merge resolution, you
454 cannot use git commit with pathnames to alter the order the changes are
455 committed, because the merge should be recorded as a single commit. In
456 fact, the command refuses to run when given pathnames (but see -i
457 option).
458
460 Author and committer information is taken from the following
461 environment variables, if set:
462 GIT_AUTHOR_NAME
464 GIT_AUTHOR_EMAIL
465 GIT_AUTHOR_DATE
466 GIT_COMMITTER_NAME
467 GIT_COMMITTER_EMAIL
468 GIT_COMMITTER_DATE
469 (nb "<", ">" and "\n"s are stripped)
471 The author and committer names are by convention some form of a
473 personal name (that is, the name by which other humans refer to you),
474 although Git does not enforce or require any particular form. Arbitrary
475 Unicode may be used, subject to the constraints listed above. This name
476 has no effect on authentication; for that, see the credential.username
477 variable in git-config(1).
478 In case (some of) these environment variables are not set, the
480 information is taken from the configuration items user.name and
481 user.email, or, if not present, the environment variable EMAIL, or, if
482 that is not set, system user name and the hostname used for outgoing
483 mail (taken from /etc/mailname and falling back to the fully qualified
484 hostname when that file does not exist).
485 The author.name and committer.name and their corresponding email
487 options override user.name and user.email if set and are overridden
488 themselves by the environment variables.
489 The typical usage is to set just the user.name and user.email
491 variables; the other options are provided for more complex use cases.
492
494 The GIT_AUTHOR_DATE and GIT_COMMITTER_DATE environment variables
495 support the following date formats:
496 Git internal format
498 It is <unix-timestamp> <time-zone-offset>, where <unix-timestamp>
499 is the number of seconds since the UNIX epoch. <time-zone-offset>
500 is a positive or negative offset from UTC. For example CET (which
501 is 1 hour ahead of UTC) is +0100.
502 RFC 2822
504 The standard email format as described by RFC 2822, for example
505 Thu, 07 Apr 2005 22:13:13 +0200.
506 ISO 8601
508 Time and date specified by the ISO 8601 standard, for example
509 2005-04-07T22:13:13. The parser accepts a space instead of the T
510 character as well. Fractional parts of a second will be ignored,
511 for example 2005-04-07T22:13:13.019 will be treated as
512 2005-04-07T22:13:13.
513 Note
515 In addition, the date part is accepted in the following
516 formats: YYYY.MM.DD, MM/DD/YYYY and DD.MM.YYYY.
517 In addition to recognizing all date formats above, the --date option
519 will also try to make sense of other, more human-centric date formats,
520 such as relative dates like "yesterday" or "last Friday at noon".
521
523 Though not required, it’s a good idea to begin the commit message with
524 a single short (less than 50 character) line summarizing the change,
525 followed by a blank line and then a more thorough description. The text
526 up to the first blank line in a commit message is treated as the commit
527 title, and that title is used throughout Git. For example, git-format-
528 patch(1) turns a commit into email, and it uses the title on the
529 Subject line and the rest of the commit in the body.
530 Git is to some extent character encoding agnostic.
532 • The contents of the blob objects are uninterpreted sequences of
534 bytes. There is no encoding translation at the core level.
535 • Path names are encoded in UTF-8 normalization form C. This applies
537 to tree objects, the index file, ref names, as well as path names
538 in command line arguments, environment variables and config files
539 (.git/config (see git-config(1)), gitignore(5), gitattributes(5)
540 and gitmodules(5)).
541 Note that Git at the core level treats path names simply as
543 sequences of non-NUL bytes, there are no path name encoding
544 conversions (except on Mac and Windows). Therefore, using non-ASCII
545 path names will mostly work even on platforms and file systems that
546 use legacy extended ASCII encodings. However, repositories created
547 on such systems will not work properly on UTF-8-based systems (e.g.
548 Linux, Mac, Windows) and vice versa. Additionally, many Git-based
549 tools simply assume path names to be UTF-8 and will fail to display
550 other encodings correctly.
551 • Commit log messages are typically encoded in UTF-8, but other
553 extended ASCII encodings are also supported. This includes
554 ISO-8859-x, CP125x and many others, but not UTF-16/32, EBCDIC and
555 CJK multi-byte encodings (GBK, Shift-JIS, Big5, EUC-x, CP9xx etc.).
556 Although we encourage that the commit log messages are encoded in
558 UTF-8, both the core and Git Porcelain are designed not to force UTF-8
559 on projects. If all participants of a particular project find it more
560 convenient to use legacy encodings, Git does not forbid it. However,
561 there are a few things to keep in mind.
562 1. git commit and git commit-tree issues a warning if the commit log
564 message given to it does not look like a valid UTF-8 string, unless
565 you explicitly say your project uses a legacy encoding. The way to
566 say this is to have i18n.commitEncoding in .git/config file, like
567 this:
568 [i18n]
570 commitEncoding = ISO-8859-1
571 Commit objects created with the above setting record the value of
573 i18n.commitEncoding in its encoding header. This is to help other
574 people who look at them later. Lack of this header implies that the
575 commit log message is encoded in UTF-8.
576 2. git log, git show, git blame and friends look at the encoding
578 header of a commit object, and try to re-code the log message into
579 UTF-8 unless otherwise specified. You can specify the desired
580 output encoding with i18n.logOutputEncoding in .git/config file,
581 like this:
582 [i18n]
584 logOutputEncoding = ISO-8859-1
585 If you do not have this configuration variable, the value of
587 i18n.commitEncoding is used instead.
588 Note that we deliberately chose not to re-code the commit log message
590 when a commit is made to force UTF-8 at the commit object level,
591 because re-coding to UTF-8 is not necessarily a reversible operation.
592
594 The editor used to edit the commit log message will be chosen from the
595 GIT_EDITOR environment variable, the core.editor configuration
596 variable, the VISUAL environment variable, or the EDITOR environment
597 variable (in that order). See git-var(1) for details.
598
600 This command can run commit-msg, prepare-commit-msg, pre-commit,
601 post-commit and post-rewrite hooks. See githooks(5) for more
602 information.
603
605 $GIT_DIR/COMMIT_EDITMSG
606 This file contains the commit message of a commit in progress. If
607 git commit exits due to an error before creating a commit, any
608 commit message that has been provided by the user (e.g., in an
609 editor session) will be available in this file, but will be
610 overwritten by the next invocation of git commit.
611
613 git-add(1), git-rm(1), git-mv(1), git-merge(1), git-commit-tree(1)
614
616 Part of the git(1) suite
617Git 2.36.1 2022-05-05 GIT-COMMIT(1)