git-commit（1）手册页

每一次运行提交操作，都是对你项目作一次快照，以后可以回到这个状态，或者进行比较。

名称
git-commit - 记录对存储库的更改

概要
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] [-S[<keyid>]] [--] [<file>…​]
描述
将索引的当前内容与来自描述更改的用户的日志消息一起存储在新提交中。

要添加的内容可以用几种方式指定：

通过使用git add在使用提交命令之前递增“添加”对索引的更改（注意：即使修改后的文件也必须“添加”）;

通过使用git rm从工作树和索引中删除文件，再次使用commit命令之前;

通过将文件列出为提交命令的参数（没有 - 交互式或--patch开关），在这种情况下，提交将忽略在索引中进行的更改，而是记录列出的文件的当前内容（必须已知到Git）;

通过使用带有commit命令的-a开关，可以自动从所有已知文件（即索引中已经列出的所有文件）中“添加”更改，并自动从索引中删除已从工作树中删除的“rm”文件，然后执行实际的提交;

通过使用--interactive或--patch开关和commit命令，在完成操作之前，除索引中的内容之外，逐个决定哪些文件或块应该是提交的一部分。请参阅git-add（1）的“交互模式”部分， 了解如何操作这些模式。

--dry-run通过给出相同的一组参数（选项和路径），可以使用该选项来获得上述任何内容对下一次提交所包含内容的摘要。

如果你做了一个提交，然后立即发现一个错误，你可以使用git reset从它恢复。

OPTIONS
-一个
- 所有
告诉命令自动对已被修改和删除的文件进行分段，但是没有告诉Git的新文件不受影响。

-p
- 补丁
使用交互式补丁选择界面来选择要提交的更改。有关详细信息，请参阅git-add（1）。

-C <commit>
--reuse消息= <提交>
取一个现有的提交对象，并在创建提交时重用日志消息和作者信息（包括时间戳）。

-c <commit>
--reedit消息= <提交>
像-C一样，但-c编辑器被调用，以便用户可以进一步编辑提交消息。

--fixup = <提交>
构造一个提交消息以供使用rebase --autosquash。提交消息将成为指定提交的主题行，前缀为“fixup！”。有关详细信息，请参阅git-rebase（1）。

--squash = <提交>
构造一个提交消息以供使用rebase --autosquash。提交消息主题行取自指定的提交，前缀为“squash！”。可以与其他提交消息选项（-m/ -c/ -C/ -F）一起使用。有关详细信息，请参阅 git-rebase（1）。

--reset执笔者
当与-C / -c / - 修改选项一起使用时，或者在冲突樱桃挑选后提交时，声明结果提交的作者现在属于提交者。这也更新了作者的时间戳。

- 短
干运行时，以短格式输出。有关详细信息，请参阅 git-status（1）。意味着--dry-run。

- 科
以短格式显示分支和跟踪信息。

- 瓷
进行干式运行时，请将输出信号转换成陶瓷格式。有关详细信息，请参阅git-status（1）。意味着 --dry-run。

- 长
当进行干运行时，以长格式输出。意味着--dry-run。

-z
- 空值
显示short或porcelain状态输出时，逐字打印文件名并用NUL而不是LF来终止输入。如果没有给出格式，则暗示--porcelain输出格式。如果没有这个-z选项，带有“不寻常”字符的文件名将按照配置变量的说明引用core.quotePath （参见git-config（1））。

-F <文件>
--file = <文件>
从给定的文件中提交提交消息。使用-从标准输入读取消息。

--author = <作者>
覆盖提交作者。使用标准A U Thor <author@example.com>格式指定明确的作者。否则<author>被认为是一个模式，用于搜索该作者现有的提交（即rev-list --all -i --author = <author>）; 然后提交作者从第一个这样的提交中找到。

--date = <日期>
覆盖提交中使用的作者日期。

-m <msg>
--message = <MSG>
使用给定的<msg>作为提交消息。如果-m给出了多个选项，则它们的值被连接为单独的段落。

-t <文件>
--template = <文件>
编辑提交信息时，用给定文件中的内容启动编辑器。所述commit.template配置变量经常被用于隐含地给这个选项添加到命令。这个机制可以被那些想要引导参与者提供什么信息的提示的项目使用。如果用户退出编辑器而不编辑消息，则提交被中止。当通过其他方式（例如使用-m或-F选项）给出消息时，这不起作用。

-s
- 登出
在提交日志消息的末尾添加Sign-off-by行。签名的含义取决于项目，但它通常证明提交者有权根据相同的许可证提交这项工作，并同意开发者原始证书（参见http://developercertificate.org/获取更多信息）。

-n
--no-验证
这个选项绕过了pre-commit和commit-msg钩子。另见githooks（5）。

--allow空
通常记录与其唯一父提交完全相同的提交是一个错误，并且该命令阻止您提交这样的提交。该选项绕过了安全性，主要供外国SCM接口脚本使用。

--allow空消息
像--allow-empty这个命令主要供外国的SCM接口脚本使用。它允许你用一个空的提交消息创建一个提交，而不使用像git-commit-tree（1）这样的管道命令 。

--cleanup = <模式>
这个选项决定了在提交之前应该如何清理提供的提交信息。所述<模式>可以是strip， whitespace，verbatim，scissors或default。

跳闸
删除前后空行，尾随空格，评论和折叠连续的空行。

空白
同strip除#commentary不会被删除。

逐字
根本不要改变信息。

剪刀
相同whitespace，除了一切从（并包括）下面找到的行被截短，如果消息是要被编辑。“ #”可以用core.commentChar定制。

＃------------------------> 8 ----------------------- - 
默认
就strip好像要编辑的消息一样。否则whitespace。

默认值可以通过commit.cleanup配置变量来改变（参见git-config（1））。

-e
- 编辑
从文件中提取的消息-F，命令行 -m和从提交对象与-C通常用作提交日志消息未修改。通过此选项，您可以进一步编辑从这些源获取的消息。

--no编辑
在不启动编辑器的情况下使用选定的提交消息。例如，git commit --amend --no-edit修改提交而不更改其提交消息。

- 修改
通过创建一个新的提交来替换当前分支的提示。记录的树像往常一样准备（包括-i和-ooptions和explicit pathspec的效果），并且当从命令行中没有指定其他消息时，将使用原始提交的消息作为起点，而不是空的消息通过选项，如-m，-F，-c，等新犯有相同的父母和作者作为当前一个（该--reset-author 选项可以反对命令这一点）。

这大致相当于：

$ git reset --soft HEAD ^
$ ...做别的事情来找出正确的树...
$ git commit -c ORIG_HEAD
但可以用来修改合并提交。

如果您修改已发布的提交，则应了解重写历史的含义。（请参阅git-rebase（1）中的“从上游重新启动” ）。

--no-后重写
绕过后重写挂钩。

-一世
- 包括
在执行到目前为止的阶段性内容之前，还要在命令行上给出路径的内容。这通常不是你想要的，除非你正在完成一个冲突的合并。

-o
- 只要
通过在命令行中指定的路径获取更新的工作树内容进行提交，忽略已经为其他路径启动的任何内容。如果在命令行中给出了任何路径，这是git commit的默认操作模式 ，在这种情况下，这个选项可以省略。如果这个选项是一起指定的--amend，那么不需要指定任何路径，它可以用来修改上一次提交而不提交已经执行的更改。如果与--allow-empty 路径一起使用也不是必需的，将会创建一个空的提交。

-u [<模式>]
--untracked-文件[= <模式>]
显示未跟踪的文件。

模式参数是可选的（默认为全部），用于指定未跟踪文件的处理; 当-u不使用时，默认是正常的，即显示未跟踪的文件和目录。

可能的选项是：

否 - 不显示未跟踪的文件

正常 - 显示未跟踪的文件和目录

all - 还显示未跟踪目录中的单个文件。

可以使用git-config（1）中记录的status.showUntrackedFiles配置变量来更改默认值。

-v
--verbose
在HEAD提交和提交消息模板底部提交的内容之间显示统一的差异，以帮助用户通过提醒提交具有哪些更改来描述提交。请注意，此差异输出没有以＃开头的行。这个差异不会是提交信息的一部分。请参阅git-config（1）中的commit.verbose配置变量。

如果指定了两次，则另外显示将要提交的内容和工作文件之间的统一差异，即对被跟踪文件进行非分离更改。

-q
- 安静
禁止提交摘要消息。

--dry运行
不要创建提交，而是显示要提交的路径的列表，包含将保留未提交的本地更改的路径以及未跟踪的路径。

- 状态
在使用编辑器准备提交消息时，在提交消息模板中包含git-status（1）的输出。默认打开，但可以用来覆盖配置变量commit.status。

- 无状态
使用编辑器准备默认提交消息时，不要在提交消息模板中包含git-status（1）的输出。

-S [<KEYID>]
--gpg-SIGN [= <KEYID>]
GPG标志提交。该keyid参数是可选的，并且默认为提交者身份; 如果指定，它必须坚持选项没有空格。

--no-GPG-SIGN
commit.gpgSign设置为强制每个提交进行签名的计数器配置变量。

-
不要把更多的理由作为选择来解释。

<文件> ...
当在命令行上给出文件时，该命令将提交指定文件的内容，而不记录已经执行的更改。这些文件的内容也将在下一次提交之前进行。

日期格式
的GIT_AUTHOR_DATE，GIT_COMMITTER_DATE环境变量和--date选项支持以下日期格式：

Git内部格式
这是<unix timestamp> <time zone offset>，在这里<unix timestamp>是从unix新纪元的秒数。 <time zone offset>是UTC的正数或负数偏移量。例如CET（比UTC早1小时）是+0100。

RFC 2822
例如RFC 2822所描述的标准电子邮件格式 Thu, 07 Apr 2005 22:13:13 +0200。

ISO 8601
例如，ISO 8601标准规定的时间和日期 2005-04-07T22:13:13。解析器接受一个空格而不是 T字符。

注意
此外，日期部分接受以下格式： YYYY.MM.DD，MM/DD/YYYY和DD.MM.YYYY。
例子
在录制自己的作品时，工作树中已修改文件的内容将临时存储到一个名为“index”的临时区域，并使用git add。一个文件只能在索引而不是工作树中git reset HEAD -- <file>恢复到最后一次提交的文件，这样可以有效地恢复git add，并阻止对该文件的更改参与下一次提交。在使用这些命令构建要被提交的状态之后， git commit（不带任何路径名参数）用于记录到目前为止已经执行的操作。这是命令的最基本形式。一个例子：

$编辑hello.c
$ git rm goodbye.c
$ git add hello.c
$ git commit
在每次单独更改之后，您都可以git commit通过注意对工作树中跟踪内容的文件进行更改，git add并git rm 为您做出相应的更改。也就是说，如果你的工作树没有其他的改变，这个例子和前面的例子一样：

$编辑hello.c
$ rm goodbye.c
$ git commit -a
该命令git commit -a首先查看您的工作树，注意到您修改了hello.c并删除了goodbye.c，git add并git rm为您执行必要的操作。

在对多个文件进行分段更改之后，可以通过给出路径名来更改记录更改的顺序git commit。当给出路径名时，该命令进行提交，只记录对指定路径所做的更改：

$编辑hello.c hello.h
$ git add hello.c hello.h
$编辑Makefile
$ git commit Makefile
这使提交记录修改Makefile。演出的变化hello.c，hello.h并不包括在最终的提交。然而，他们的变化并没有失去 - 他们仍然上演，只是被阻止。经过上面的顺序，如果你这样做：

$ git commit
这第二次提交将记录变化hello.c和 hello.h预期。

合并后（由git merge或git pull启动）由于冲突而停止，干净的合并路径已经为你提交，并且冲突的路径处于未合并状态。你将不得不首先检查哪些路径与git状态相冲突， 并且在你的工作树中手动修复它们之后，你将像往常一样使用git add来分级：

$ git status | grep没有淹没
unmerged：hello.c
$编辑hello.c
$ git add hello.c
解决冲突并分级后，git ls-files -u 会停止提及冲突的路径。完成后，运行git commit以最终记录合并：

$ git commit
如同记录自己的更改的情况一样，您可以使用-a 选项来保存输入。一个区别是，在合并解析期间，不能使用git commit路径名来更改提交更改的顺序，因为合并应该记录为单个提交。实际上，命令在给定路径名时拒绝运行（但请参阅-i选项）。

讨论
尽管不是必需的，但是最好是用一个简短的（少于50个字符）行来总结这个改变，然后是一个空行，然后是一个更全面的描述。直到提交消息中的第一个空行的文本被视为提交标题，并且该标题在整个Git中使用。例如，git-format-patch（1）将一个提交转换为电子邮件，它使用主题行上的标题和正文中的其余部分。

Git在某种程度上是字符编码不可知的。

blob对象的内容是未解释的字节序列。核心层没有编码翻译。

路径名以UTF-8标准化形式C编码。这适用于树对象，索引文件，ref名称，以及命令行参数，环境变量和配置文件中的路径名.git/config（参见git-config（1）） ， gitignore（5），gitattributes（5）和 gitmodules（5））。

请注意，在核心级别的Git将路径名视为非NUL字节序列，不存在路径名编码转换（Mac和Windows除外）。因此，即使在使用传统扩展ASCII编码的平台和文件系统上，使用非ASCII路径名也是大部分工作的。但是，在这样的系统上创建的存储库在基于UTF-8的系统（例如Linux，Mac，Windows）上不能正常工作，反之亦然。此外，许多基于Git的工具只是假设路径名为UTF-8，并且无法正确显示其他编码。

提交日志消息通常以UTF-8编码，但也支持其他扩展的ASCII编码。这包括ISO-8859-x，CP125x等等，但不包括 UTF-16/32，EBCDIC和CJK多字节编码（GBK，Shift-JIS，Big5，EUC-x，CP9xx等）。

虽然我们鼓励提交日志消息使用UTF-8编码，但核心和Git瓷器都不是强制在项目上使用UTF-8。如果一个特定项目的所有参与者发现使用传统编码更方便，Git不会禁止它。但是，有几件事要记住。

git commit和git commit-tree会在提交给它的提交日志消息看起来不像一个有效的UTF-8字符串时发出警告，除非你明确地说你的项目使用了一个遗留编码。说这个的方法是在.git/config文件中有i18n.commitencoding ，就像这样：

[I18N]
commitEncoding = ISO-8859-1
使用上述设置创建的提交对象记录i18n.commitEncoding其encoding标题中的值。这是为了帮助其他人稍后看到他们。缺少这个头文件意味着提交日志消息以UTF-8编码。

git log，git show，git blame和朋友看encoding一个提交对象的 头文件，除非另外指定，否则尝试将日志消息重新编码为UTF-8。您可以i18n.logOutputEncoding在.git/config文件中指定所需的输出编码 ，如下所示：

[I18N]
logOutputEncoding = ISO-8859-1
如果您没有此配置变量，i18n.commitEncoding则使用该值 。

请注意，在提交对象级别强制使用UTF-8时，我们故意选择不重新编写提交日志消息，因为重新编码为UTF-8不一定是可逆操作。

环境和配置变量
用于编辑提交日志消息的编辑器将从 GIT_EDITOR环境变量，core.editor配置变量，VISUAL环境变量或EDITOR环境变量（按此 顺序）中进行选择。有关详细信息，请参阅git-var（1）。

挂钩
这个命令可以运行commit-msg，prepare-commit-msg，pre-commit， post-commit和post-rewrite挂钩。请参阅githooks（5）了解更多信息。

FILES
$GIT_DIR/COMMIT_EDITMSG
该文件包含正在进行的提交的提交消息。如果git commit在创建提交之前由于错误而退出，则用户提供的任何提交消息（例如，在编辑器会话中）都将在此文件中可用，但将在下一次调用时被覆盖git commit。

也可以看看
git-add（1）， git-rm（1）， git-mv（1）， git-merge（1）， git-commit-tree（1）

GIT
所述的部分的git（1）套件

最后更新2018-02-02 16:16:03协调世界时