| git-commit(1) |
| ============= |
| |
| NAME |
| ---- |
| git-commit - Record changes to the repository |
| |
| SYNOPSIS |
| -------- |
| [verse] |
| 'git commit' [-a | --interactive | --patch] [-s] [-v] [-u<mode>] [--amend] |
| [--dry-run] [(-c | -C | --fixup | --squash) <commit>] |
| [-F <file> | -m <msg>] [--reset-author] [--allow-empty] |
| [--allow-empty-message] [--no-verify] [-e] [--author=<author>] |
| [--date=<date>] [--cleanup=<mode>] [--[no-]status] |
| [-i | -o] [--pathspec-from-file=<file> [--pathspec-file-nul]] |
| [-S[<keyid>]] [--] [<pathspec>...] |
| |
| DESCRIPTION |
| ----------- |
| Create a new commit containing the current contents of the index and |
| the given log message describing the changes. The new commit is a |
| direct child of HEAD, usually the tip of the current branch, and the |
| branch is updated to point to it (unless no branch is associated with |
| the working tree, in which case HEAD is "detached" as described in |
| linkgit:git-checkout[1]). |
| |
| The content to be committed can be specified in several ways: |
| |
| 1. by using linkgit:git-add[1] to incrementally "add" changes to the |
| index before using the 'commit' command (Note: even modified files |
| must be "added"); |
| |
| 2. by using linkgit:git-rm[1] to remove files from the working tree |
| and the index, again before using the 'commit' command; |
| |
| 3. by listing files as arguments to the 'commit' command |
| (without --interactive or --patch switch), in which |
| case the commit will ignore changes staged in the index, and instead |
| record the current content of the listed files (which must already |
| be known to Git); |
| |
| 4. by using the -a switch with the 'commit' command to automatically |
| "add" changes from all known files (i.e. all files that are already |
| listed in the index) and to automatically "rm" files in the index |
| that have been removed from the working tree, and then perform the |
| actual commit; |
| |
| 5. by using the --interactive or --patch switches with the 'commit' command |
| to decide one by one which files or hunks should be part of the commit |
| in addition to contents in the index, |
| before finalizing the operation. See the ``Interactive Mode'' section of |
| linkgit:git-add[1] to learn how to operate these modes. |
| |
| The `--dry-run` option can be used to obtain a |
| summary of what is included by any of the above for the next |
| commit by giving the same set of parameters (options and paths). |
| |
| If you make a commit and then find a mistake immediately after |
| that, you can recover from it with 'git reset'. |
| |
| |
| OPTIONS |
| ------- |
| -a:: |
| --all:: |
| Tell the command to automatically stage files that have |
| been modified and deleted, but new files you have not |
| told Git about are not affected. |
| |
| -p:: |
| --patch:: |
| Use the interactive patch selection interface to chose |
| which changes to commit. See linkgit:git-add[1] for |
| details. |
| |
| -C <commit>:: |
| --reuse-message=<commit>:: |
| Take an existing commit object, and reuse the log message |
| and the authorship information (including the timestamp) |
| when creating the commit. |
| |
| -c <commit>:: |
| --reedit-message=<commit>:: |
| Like '-C', but with `-c` the editor is invoked, so that |
| the user can further edit the commit message. |
| |
| --fixup=<commit>:: |
| Construct a commit message for use with `rebase --autosquash`. |
| The commit message will be the subject line from the specified |
| commit with a prefix of "fixup! ". See linkgit:git-rebase[1] |
| for details. |
| |
| --squash=<commit>:: |
| Construct a commit message for use with `rebase --autosquash`. |
| The commit message subject line is taken from the specified |
| commit with a prefix of "squash! ". Can be used with additional |
| commit message options (`-m`/`-c`/`-C`/`-F`). See |
| linkgit:git-rebase[1] for details. |
| |
| --reset-author:: |
| When used with -C/-c/--amend options, or when committing after a |
| conflicting cherry-pick, declare that the authorship of the |
| resulting commit now belongs to the committer. This also renews |
| the author timestamp. |
| |
| --short:: |
| When doing a dry-run, give the output in the short-format. See |
| linkgit:git-status[1] for details. Implies `--dry-run`. |
| |
| --branch:: |
| Show the branch and tracking info even in short-format. |
| |
| --porcelain:: |
| When doing a dry-run, give the output in a porcelain-ready |
| format. See linkgit:git-status[1] for details. Implies |
| `--dry-run`. |
| |
| --long:: |
| When doing a dry-run, give the output in the long-format. |
| Implies `--dry-run`. |
| |
| -z:: |
| --null:: |
| When showing `short` or `porcelain` status output, print the |
| filename verbatim and terminate the entries with NUL, instead of LF. |
| If no format is given, implies the `--porcelain` output format. |
| Without the `-z` option, filenames with "unusual" characters are |
| quoted as explained for the configuration variable `core.quotePath` |
| (see linkgit:git-config[1]). |
| |
| -F <file>:: |
| --file=<file>:: |
| Take the commit message from the given file. Use '-' to |
| read the message from the standard input. |
| |
| --author=<author>:: |
| Override the commit author. Specify an explicit author using the |
| standard `A U Thor <author@example.com>` format. Otherwise <author> |
| is assumed to be a pattern and is used to search for an existing |
| commit by that author (i.e. rev-list --all -i --author=<author>); |
| the commit author is then copied from the first such commit found. |
| |
| --date=<date>:: |
| Override the author date used in the commit. |
| |
| -m <msg>:: |
| --message=<msg>:: |
| Use the given <msg> as the commit message. |
| If multiple `-m` options are given, their values are |
| concatenated as separate paragraphs. |
| + |
| The `-m` option is mutually exclusive with `-c`, `-C`, and `-F`. |
| |
| -t <file>:: |
| --template=<file>:: |
| When editing the commit message, start the editor with the |
| contents in the given file. The `commit.template` configuration |
| variable is often used to give this option implicitly to the |
| command. This mechanism can be used by projects that want to |
| guide participants with some hints on what to write in the message |
| in what order. If the user exits the editor without editing the |
| message, the commit is aborted. This has no effect when a message |
| is given by other means, e.g. with the `-m` or `-F` options. |
| |
| -s:: |
| --signoff:: |
| Add Signed-off-by line by the committer at the end of the commit |
| log message. The meaning of a signoff depends on the project, |
| but it typically certifies that committer has |
| the rights to submit this work under the same license and |
| agrees to a Developer Certificate of Origin |
| (see http://developercertificate.org/ for more information). |
| |
| -n:: |
| --no-verify:: |
| This option bypasses the pre-commit and commit-msg hooks. |
| See also linkgit:githooks[5]. |
| |
| --allow-empty:: |
| Usually recording a commit that has the exact same tree as its |
| sole parent commit is a mistake, and the command prevents you |
| from making such a commit. This option bypasses the safety, and |
| is primarily for use by foreign SCM interface scripts. |
| |
| --allow-empty-message:: |
| Like --allow-empty this command is primarily for use by foreign |
| SCM interface scripts. It allows you to create a commit with an |
| empty commit message without using plumbing commands like |
| linkgit:git-commit-tree[1]. |
| |
| --cleanup=<mode>:: |
| This option determines how the supplied commit message should be |
| cleaned up before committing. The '<mode>' can be `strip`, |
| `whitespace`, `verbatim`, `scissors` or `default`. |
| + |
| -- |
| strip:: |
| Strip leading and trailing empty lines, trailing whitespace, |
| commentary and collapse consecutive empty lines. |
| whitespace:: |
| Same as `strip` except #commentary is not removed. |
| verbatim:: |
| Do not change the message at all. |
| scissors:: |
| Same as `whitespace` except that everything from (and including) |
| the line found below is truncated, if the message is to be edited. |
| "`#`" can be customized with core.commentChar. |
| |
| # ------------------------ >8 ------------------------ |
| |
| default:: |
| Same as `strip` if the message is to be edited. |
| Otherwise `whitespace`. |
| -- |
| + |
| The default can be changed by the `commit.cleanup` configuration |
| variable (see linkgit:git-config[1]). |
| |
| -e:: |
| --edit:: |
| The message taken from file with `-F`, command line with |
| `-m`, and from commit object with `-C` are usually used as |
| the commit log message unmodified. This option lets you |
| further edit the message taken from these sources. |
| |
| --no-edit:: |
| Use the selected commit message without launching an editor. |
| For example, `git commit --amend --no-edit` amends a commit |
| without changing its commit message. |
| |
| --amend:: |
| Replace the tip of the current branch by creating a new |
| commit. The recorded tree is prepared as usual (including |
| the effect of the `-i` and `-o` options and explicit |
| pathspec), and the message from the original commit is used |
| as the starting point, instead of an empty message, when no |
| other message is specified from the command line via options |
| such as `-m`, `-F`, `-c`, etc. The new commit has the same |
| parents and author as the current one (the `--reset-author` |
| option can countermand this). |
| + |
| -- |
| It is a rough equivalent for: |
| ------ |
| $ git reset --soft HEAD^ |
| $ ... do something else to come up with the right tree ... |
| $ git commit -c ORIG_HEAD |
| |
| ------ |
| but can be used to amend a merge commit. |
| -- |
| + |
| You should understand the implications of rewriting history if you |
| amend a commit that has already been published. (See the "RECOVERING |
| FROM UPSTREAM REBASE" section in linkgit:git-rebase[1].) |
| |
| --no-post-rewrite:: |
| Bypass the post-rewrite hook. |
| |
| -i:: |
| --include:: |
| Before making a commit out of staged contents so far, |
| stage the contents of paths given on the command line |
| as well. This is usually not what you want unless you |
| are concluding a conflicted merge. |
| |
| -o:: |
| --only:: |
| Make a commit by taking the updated working tree contents |
| of the paths specified on the |
| command line, disregarding any contents that have been |
| staged for other paths. This is the default mode of operation of |
| 'git commit' if any paths are given on the command line, |
| in which case this option can be omitted. |
| If this option is specified together with `--amend`, then |
| no paths need to be specified, which can be used to amend |
| the last commit without committing changes that have |
| already been staged. If used together with `--allow-empty` |
| paths are also not required, and an empty commit will be created. |
| |
| --pathspec-from-file=<file>:: |
| Pathspec is passed in `<file>` instead of commandline args. If |
| `<file>` is exactly `-` then standard input is used. Pathspec |
| elements are separated by LF or CR/LF. Pathspec elements can be |
| quoted as explained for the configuration variable `core.quotePath` |
| (see linkgit:git-config[1]). See also `--pathspec-file-nul` and |
| global `--literal-pathspecs`. |
| |
| --pathspec-file-nul:: |
| Only meaningful with `--pathspec-from-file`. Pathspec elements are |
| separated with NUL character and all other characters are taken |
| literally (including newlines and quotes). |
| |
| -u[<mode>]:: |
| --untracked-files[=<mode>]:: |
| Show untracked files. |
| + |
| -- |
| The mode parameter is optional (defaults to 'all'), and is used to |
| specify the handling of untracked files; when -u is not used, the |
| default is 'normal', i.e. show untracked files and directories. |
| |
| The possible options are: |
| |
| - 'no' - Show no untracked files |
| - 'normal' - Shows untracked files and directories |
| - 'all' - Also shows individual files in untracked directories. |
| |
| The default can be changed using the status.showUntrackedFiles |
| configuration variable documented in linkgit:git-config[1]. |
| -- |
| |
| -v:: |
| --verbose:: |
| Show unified diff between the HEAD commit and what |
| would be committed at the bottom of the commit message |
| template to help the user describe the commit by reminding |
| what changes the commit has. |
| Note that this diff output doesn't have its |
| lines prefixed with '#'. This diff will not be a part |
| of the commit message. See the `commit.verbose` configuration |
| variable in linkgit:git-config[1]. |
| + |
| If specified twice, show in addition the unified diff between |
| what would be committed and the worktree files, i.e. the unstaged |
| changes to tracked files. |
| |
| -q:: |
| --quiet:: |
| Suppress commit summary message. |
| |
| --dry-run:: |
| Do not create a commit, but show a list of paths that are |
| to be committed, paths with local changes that will be left |
| uncommitted and paths that are untracked. |
| |
| --status:: |
| Include the output of linkgit:git-status[1] in the commit |
| message template when using an editor to prepare the commit |
| message. Defaults to on, but can be used to override |
| configuration variable commit.status. |
| |
| --no-status:: |
| Do not include the output of linkgit:git-status[1] in the |
| commit message template when using an editor to prepare the |
| default commit message. |
| |
| -S[<keyid>]:: |
| --gpg-sign[=<keyid>]:: |
| GPG-sign commits. The `keyid` argument is optional and |
| defaults to the committer identity; if specified, it must be |
| stuck to the option without a space. |
| |
| --no-gpg-sign:: |
| Countermand `commit.gpgSign` configuration variable that is |
| set to force each and every commit to be signed. |
| |
| \--:: |
| Do not interpret any more arguments as options. |
| |
| <pathspec>...:: |
| When pathspec is given on the command line, commit the contents of |
| the files that match the pathspec without recording the changes |
| already added to the index. The contents of these files are also |
| staged for the next commit on top of what have been staged before. |
| + |
| For more details, see the 'pathspec' entry in linkgit:gitglossary[7]. |
| |
| EXAMPLES |
| -------- |
| When recording your own work, the contents of modified files in |
| your working tree are temporarily stored to a staging area |
| called the "index" with 'git add'. A file can be |
| reverted back, only in the index but not in the working tree, |
| to that of the last commit with `git restore --staged <file>`, |
| which effectively reverts 'git add' and prevents the changes to |
| this file from participating in the next commit. After building |
| the state to be committed incrementally with these commands, |
| `git commit` (without any pathname parameter) is used to record what |
| has been staged so far. This is the most basic form of the |
| command. An example: |
| |
| ------------ |
| $ edit hello.c |
| $ git rm goodbye.c |
| $ git add hello.c |
| $ git commit |
| ------------ |
| |
| Instead of staging files after each individual change, you can |
| tell `git commit` to notice the changes to the files whose |
| contents are tracked in |
| your working tree and do corresponding `git add` and `git rm` |
| for you. That is, this example does the same as the earlier |
| example if there is no other change in your working tree: |
| |
| ------------ |
| $ edit hello.c |
| $ rm goodbye.c |
| $ git commit -a |
| ------------ |
| |
| The command `git commit -a` first looks at your working tree, |
| notices that you have modified hello.c and removed goodbye.c, |
| and performs necessary `git add` and `git rm` for you. |
| |
| After staging changes to many files, you can alter the order the |
| changes are recorded in, by giving pathnames to `git commit`. |
| When pathnames are given, the command makes a commit that |
| only records the changes made to the named paths: |
| |
| ------------ |
| $ edit hello.c hello.h |
| $ git add hello.c hello.h |
| $ edit Makefile |
| $ git commit Makefile |
| ------------ |
| |
| This makes a commit that records the modification to `Makefile`. |
| The changes staged for `hello.c` and `hello.h` are not included |
| in the resulting commit. However, their changes are not lost -- |
| they are still staged and merely held back. After the above |
| sequence, if you do: |
| |
| ------------ |
| $ git commit |
| ------------ |
| |
| this second commit would record the changes to `hello.c` and |
| `hello.h` as expected. |
| |
| After a merge (initiated by 'git merge' or 'git pull') stops |
| because of conflicts, cleanly merged |
| paths are already staged to be committed for you, and paths that |
| conflicted are left in unmerged state. You would have to first |
| check which paths are conflicting with 'git status' |
| and after fixing them manually in your working tree, you would |
| stage the result as usual with 'git add': |
| |
| ------------ |
| $ git status | grep unmerged |
| unmerged: hello.c |
| $ edit hello.c |
| $ git add hello.c |
| ------------ |
| |
| After resolving conflicts and staging the result, `git ls-files -u` |
| would stop mentioning the conflicted path. When you are done, |
| run `git commit` to finally record the merge: |
| |
| ------------ |
| $ git commit |
| ------------ |
| |
| As with the case to record your own changes, you can use `-a` |
| option to save typing. One difference is that during a merge |
| resolution, you cannot use `git commit` with pathnames to |
| alter the order the changes are committed, because the merge |
| should be recorded as a single commit. In fact, the command |
| refuses to run when given pathnames (but see `-i` option). |
| |
| COMMIT INFORMATION |
| ------------------ |
| |
| Author and committer information is taken from the following environment |
| variables, if set: |
| |
| GIT_AUTHOR_NAME |
| GIT_AUTHOR_EMAIL |
| GIT_AUTHOR_DATE |
| GIT_COMMITTER_NAME |
| GIT_COMMITTER_EMAIL |
| GIT_COMMITTER_DATE |
| |
| (nb "<", ">" and "\n"s are stripped) |
| |
| The author and committer names are by convention some form of a personal name |
| (that is, the name by which other humans refer to you), although Git does not |
| enforce or require any particular form. Arbitrary Unicode may be used, subject |
| to the constraints listed above. This name has no effect on authentication; for |
| that, see the `credential.username` variable in linkgit:git-config[1]. |
| |
| In case (some of) these environment variables are not set, the information |
| is taken from the configuration items `user.name` and `user.email`, or, if not |
| present, the environment variable EMAIL, or, if that is not set, |
| system user name and the hostname used for outgoing mail (taken |
| from `/etc/mailname` and falling back to the fully qualified hostname when |
| that file does not exist). |
| |
| The `author.name` and `committer.name` and their corresponding email options |
| override `user.name` and `user.email` if set and are overridden themselves by |
| the environment variables. |
| |
| The typical usage is to set just the `user.name` and `user.email` variables; |
| the other options are provided for more complex use cases. |
| |
| :git-commit: 1 |
| include::date-formats.txt[] |
| |
| DISCUSSION |
| ---------- |
| |
| Though not required, it's a good idea to begin the commit message |
| with a single short (less than 50 character) line summarizing the |
| change, followed by a blank line and then a more thorough description. |
| The text up to the first blank line in a commit message is treated |
| as the commit title, and that title is used throughout Git. |
| For example, linkgit:git-format-patch[1] turns a commit into email, and it uses |
| the title on the Subject line and the rest of the commit in the body. |
| |
| include::i18n.txt[] |
| |
| ENVIRONMENT AND CONFIGURATION VARIABLES |
| --------------------------------------- |
| The editor used to edit the commit log message will be chosen from the |
| `GIT_EDITOR` environment variable, the core.editor configuration variable, the |
| `VISUAL` environment variable, or the `EDITOR` environment variable (in that |
| order). See linkgit:git-var[1] for details. |
| |
| HOOKS |
| ----- |
| This command can run `commit-msg`, `prepare-commit-msg`, `pre-commit`, |
| `post-commit` and `post-rewrite` hooks. See linkgit:githooks[5] for more |
| information. |
| |
| FILES |
| ----- |
| |
| `$GIT_DIR/COMMIT_EDITMSG`:: |
| This file contains the commit message of a commit in progress. |
| If `git commit` exits due to an error before creating a commit, |
| any commit message that has been provided by the user (e.g., in |
| an editor session) will be available in this file, but will be |
| overwritten by the next invocation of `git commit`. |
| |
| SEE ALSO |
| -------- |
| linkgit:git-add[1], |
| linkgit:git-rm[1], |
| linkgit:git-mv[1], |
| linkgit:git-merge[1], |
| linkgit:git-commit-tree[1] |
| |
| GIT |
| --- |
| Part of the linkgit:git[1] suite |