1GIT-COMMIT(1)                     Git Manual                     GIT-COMMIT(1)
2
3
4

NAME

6       git-commit - Record changes to the repository
7

SYNOPSIS

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

DESCRIPTION

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
26       The content to be committed can be specified in several ways:
27
28        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
32        2. by using git-rm(1) to remove files from the working tree and the
33           index, again before using the commit command;
34
35        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
40        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
46        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
52       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
56       If you make a commit and then find a mistake immediately after that,
57       you can recover from it with git reset.
58

OPTIONS

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
65       -p, --patch
66           Use the interactive patch selection interface to choose which
67           changes to commit. See git-add(1) for details.
68
69       -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
74       -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
78       --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
89           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
96           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
105           --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
111           Neither "fixup!" nor "amend!" commits change authorship of <commit>
112           when applied by git rebase --autosquash. See git-rebase(1) for
113           details.
114
115       --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
121       --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
127       --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
131       --branch
132           Show the branch and tracking info even in short-format.
133
134       --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
138       --long
139           When doing a dry-run, give the output in the long-format. Implies
140           --dry-run.
141
142       -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
150       -F <file>, --file=<file>
151           Take the commit message from the given file. Use - to read the
152           message from the standard input.
153
154       --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
161       --date=<date>
162           Override the author date used in the commit.
163
164       -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
168           The -m option is mutually exclusive with -c, -C, and -F.
169
170       -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
180       -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
192           The --no-signoff option can be used to countermand an earlier
193           --signoff option on the command line.
194
195       --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
205       -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
210       --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
216       --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
222       --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
227           strip
228               Strip leading and trailing empty lines, trailing whitespace,
229               commentary and collapse consecutive empty lines.
230
231           whitespace
232               Same as strip except #commentary is not removed.
233
234           verbatim
235               Do not change the message at all.
236
237           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
242                   # ------------------------ >8 ------------------------
243
244           default
245               Same as strip if the message is to be edited. Otherwise
246               whitespace.
247
248           The default can be changed by the commit.cleanup configuration
249           variable (see git-config(1)).
250
251       -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
257       --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
262       --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
272           It is a rough equivalent for:
273
274                       $ git reset --soft HEAD^
275                       $ ... do something else to come up with the right tree ...
276                       $ git commit -c ORIG_HEAD
277
278           but can be used to amend a merge commit.
279
280           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
284       --no-post-rewrite
285           Bypass the post-rewrite hook.
286
287       -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
293       -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
305       --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
313       --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
318       -u[<mode>], --untracked-files[=<mode>]
319           Show untracked files.
320
321           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
325           The possible options are:
326
327no - Show no untracked files
328
329normal - Shows untracked files and directories
330
331all - Also shows individual files in untracked directories.
332
333           The default can be changed using the status.showUntrackedFiles
334           configuration variable documented in git-config(1).
335
336       -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
344           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
348       -q, --quiet
349           Suppress commit summary message.
350
351       --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
356       --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
361       --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
366       -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
372       --
373           Do not interpret any more arguments as options.
374
375       <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
381           For more details, see the pathspec entry in gitglossary(7).
382

EXAMPLES

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
395           $ edit hello.c
396           $ git rm goodbye.c
397           $ git add hello.c
398           $ git commit
399
400       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
406           $ edit hello.c
407           $ rm goodbye.c
408           $ git commit -a
409
410       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
414       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
419           $ edit hello.c hello.h
420           $ git add hello.c hello.h
421           $ edit Makefile
422           $ git commit Makefile
423
424       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
429           $ git commit
430
431       this second commit would record the changes to hello.c and hello.h as
432       expected.
433
434       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
441           $ git status | grep unmerged
442           unmerged: hello.c
443           $ edit hello.c
444           $ git add hello.c
445
446       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
450           $ git commit
451
452       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

COMMIT INFORMATION

460       Author and committer information is taken from the following
461       environment variables, if set:
462
463           GIT_AUTHOR_NAME
464           GIT_AUTHOR_EMAIL
465           GIT_AUTHOR_DATE
466           GIT_COMMITTER_NAME
467           GIT_COMMITTER_EMAIL
468           GIT_COMMITTER_DATE
469
470       (nb "<", ">" and "\n"s are stripped)
471
472       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
479       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
486       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
490       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

DATE FORMATS

494       The GIT_AUTHOR_DATE and GIT_COMMITTER_DATE environment variables
495       support the following date formats:
496
497       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
503       RFC 2822
504           The standard email format as described by RFC 2822, for example
505           Thu, 07 Apr 2005 22:13:13 +0200.
506
507       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
514               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
518       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

DISCUSSION

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
531       Git is to some extent character encoding agnostic.
532
533       •   The contents of the blob objects are uninterpreted sequences of
534           bytes. There is no encoding translation at the core level.
535
536       •   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
542           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
552       •   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
557       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
563        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
569               [i18n]
570                       commitEncoding = ISO-8859-1
571
572           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
577        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
583               [i18n]
584                       logOutputEncoding = ISO-8859-1
585
586           If you do not have this configuration variable, the value of
587           i18n.commitEncoding is used instead.
588
589       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

ENVIRONMENT AND CONFIGURATION VARIABLES

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
599       Everything above this line in this section isn’t included from the git-
600       config(1) documentation. The content that follows is the same as what’s
601       found there:
602
603       commit.cleanup
604           This setting overrides the default of the --cleanup option in git
605           commit. See git-commit(1) for details. Changing the default can be
606           useful when you always want to keep lines that begin with comment
607           character # in your log message, in which case you would do git
608           config commit.cleanup whitespace (note that you will have to remove
609           the help lines that begin with # in the commit log template
610           yourself, if you do this).
611
612       commit.gpgSign
613           A boolean to specify whether all commits should be GPG signed. Use
614           of this option when doing operations such as rebase can result in a
615           large number of commits being signed. It may be convenient to use
616           an agent to avoid typing your GPG passphrase several times.
617
618       commit.status
619           A boolean to enable/disable inclusion of status information in the
620           commit message template when using an editor to prepare the commit
621           message. Defaults to true.
622
623       commit.template
624           Specify the pathname of a file to use as the template for new
625           commit messages.
626
627       commit.verbose
628           A boolean or int to specify the level of verbose with git commit.
629           See git-commit(1).
630

HOOKS

632       This command can run commit-msg, prepare-commit-msg, pre-commit,
633       post-commit and post-rewrite hooks. See githooks(5) for more
634       information.
635

FILES

637       $GIT_DIR/COMMIT_EDITMSG
638           This file contains the commit message of a commit in progress. If
639           git commit exits due to an error before creating a commit, any
640           commit message that has been provided by the user (e.g., in an
641           editor session) will be available in this file, but will be
642           overwritten by the next invocation of git commit.
643

SEE ALSO

645       git-add(1), git-rm(1), git-mv(1), git-merge(1), git-commit-tree(1)
646

GIT

648       Part of the git(1) suite
649
650
651
652Git 2.39.1                        2023-01-13                     GIT-COMMIT(1)
Impressum