git commit
Name
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在使用commit命令之前使用增量“增加”索引更改（注意：即使修改过的文件也必须“添加”）;
2. 通过git rm删除从工作树和索引文件，再次使用前commit命令;
3 . 通过将文件列为参数commit（不带--interactive或--patch开关），在这种情况下，提交将忽略在索引中执行的更改，而是记录列出的文件的当前内容（必须已知GIT）;
4 . 通过使用带commit命令的-a开关自动从所有已知文件（即索引中已列出的所有文件）中“添加”更改，并自动从索引中删除工作树中的“rm”文件，然后执行实际提交;
5. 通过使用--interactive或--patch开关和commit命令，在完成操作之前，除索引中的内容之外，逐个决定哪些文件或块应该是提交的一部分。请参阅git-add [1]的“交互模式”部分了解如何操作这些模式。该--dry-run选项可用于通过给出相同的一组参数（选项和路径）。如果你提交了一个提交，然后在那之后立即发现一个错误，你可以用它来恢复git reset.Options -a --all告诉命令自动对已被修改和删除的文件进行分段，但没有告知Git的新文件不受影响。-p --patch使用交互式补丁选择界面来选择要提交的更改。有关详细信息，请参阅git-add [1]。-C <commit> --reuse-message = <commit>取一个现有的提交对象，并在创建提交时重用日志消息和作者信息（包括时间戳）。-c <commit> --reedit-message = <commit>好像-C，但是-c调用了编辑器，以便用户可以进一步编辑提交消息。--fixup = <commit>构造一个提交消息以供使用rebase --autosquash。提交消息将成为指定提交的主题行，其前缀为“fixup！”。有关详细信息，请参阅git-rebase [1]。--squash = <commit>构造一个提交消息以供使用rebase --autosquash。提交消息主题行取自指定的提交，前缀为“squash！”。可以与其他提交消息选项（-m/ -c/ -C/ -F）一起使用。有关详细信息，请参阅git-rebase [1]。--reset-author当与-C / -c / - 修改选项一起使用时，或者在冲突樱桃挑选后提交时，声明结果提交的作者现在属于提交者。这也会更新作者的时间戳。 - short当进行干运行时，以短格式输出输出。有关详细信息，请参阅git-status [1]。暗示--dry-run。--branch甚至以短格式显示分支和跟踪信息。 - 陶瓷当进行干式运行时，请以陶瓷准备好的格式输出。有关详细信息，请参阅git-status [1]。意味着--dry-run。 - 长时间运行时，以长格式输出。意味着--dry-run。-z --null当显示short或porcelain状态输出时，逐字打印文件名并用NUL而不是LF结束输入。如果没有给出格式，则表示--porcelain输出格式。如果没有这个-z选项，带有“不寻常”字符的文件名将按照配置变量的说明引用core.quotePath（请参阅git-config [1]）。-F <file> --file = <file>从给定文件中获取提交消息。使用-从标准输入读取消息。--author = <author>覆盖提交作者。使用标准A U Thor <author@example.com>格式指定明确的作者。否则<author>被认为是一个模式，用于搜索该作者现有的提交（即rev-list --all -i --author = <author>）; 然后从第一个找到的提交中复制提交作者。--date = <date>覆盖提交中使用的作者日期。-m <msg> --message = <msg>使用给定的<msg>作为提交消息。如果-m给出了多个选项，则它们的值被连接为单独的段落。-t <file> --template = <file>编辑提交信息时，用给定文件中的内容启动编辑器。该commit.template配置变量通常用于隐式地将该选项赋予命令。这种机制可以被那些想要引导参与者提供什么信息以什么顺序写在消息中的暗示的项目使用。如果用户退出编辑器而不编辑消息，则提交将中止。当通过其他方式给出消息时，例如使用-m或-F选项，这不起作用。-s --signoff在提交日志消息结尾添加Sign-off-by行。签名的含义取决于项目，但它通常证明提交者有权根据相同的许可证提交此项工作，并同意开发者原始证书（参见http://developercertificate.org/）。了解更多信息）。-n --no-verify这个选项绕过预先提交和提交msg钩子。另见githooks [5]。--allow-empty通常记录与其唯一父提交完全相同的提交是一个错误，并且该命令阻止您进行此类提交。此选项绕过安全性，主要供外国SCM接口脚本使用。--allow-empty-message与--allow-empty一样，此命令主要供外部SCM接口脚本使用。它允许你使用空的提交消息创建一个提交，而不使用像git-commit-tree [1]这样的管道命令。--cleanup = <mode>该选项确定在提交之前应如何清理提供的提交消息。该<mode>可strip，whitespace，verbatim，scissors或者default。带剥离前导和尾随空行，尾随空白，评论和折叠连续的空行。空格与＃strip注释相同，不会被删除。逐字不要改变信息。剪刀whitespace除了从下面找到的行（包括下面的行）中的所有内容被截断之后，如果要编辑的消息都一样。“ #”可以用core.commentChar自定义。＃------------------------> 8 ------------- ----------- default与strip消息编辑相同。否则whitespace。默认值可以通过commit.cleanup配置变量进行更改（请参阅git-config [1]）。-e --edit从文件中提取的消息-F，命令行-m和从提交对象中提取的消息-C通常用作未修改的提交日志消息。该选项可让您进一步编辑从这些源获取的消息。--no-edit在不启动编辑器的情况下使用选定的提交消息。例如，git commit --amend --no-edit修改提交而不更改其提交消息。--amend通过创建一个新的提交来替换当前分支的提示。记录的树像往常一样准备（包括-i和-o选项和显式pathspec的效果），并且当从命令行中未指定其他消息时，将使用原始提交的消息作为起点，而不是空消息通过选项，如-m，-F，-c，等新犯有相同的父母和作者作为当前一个（在--reset-author选项可以反制这个）。它是一个粗略的等价物：$ git reset --soft HEAD ^ $ ...做一些其他的事情来得到正确的树... $ git commit -c ORIG_HEADbut可以用来修改一个合并提交。如果您修改已发布的提交，您应该了解重写历史记录的含义。（请参阅git-rebase [1]中的“从上行链路重新启动”部分）。--no-post-rewrite绕过重写后挂钩。-i --include在到目前为止的阶段性内容提交之前，还要在命令行上给出路径的内容。这通常不是你想要的，除非你正在完成一个冲突的合并。-o - 仅通过获取命令行中指定路径的更新工作树内容来进行提交，无视任何已经为其他路径上演的内容。这是默认的操作模式git commit如果在命令行上给出了任何路径，在这种情况下，该选项可以省略。如果此选项与“一起指定” --amend，则不需要指定任何路径，可以使用这些路径修改上次提交而不提交已经执行的更改。如果与--allow-empty路径一起使用也不是必需的，并且将创建一个空的提交。-u <mode> --untracked-files = <mode>显示未跟踪的文件。模式参数是可选的（默认为all），用于指定处理未跟踪的文件; 当-u未使用时，默认值是normal，即显示未跟踪的文件和目录。可能的选项是：
no- 不显示未跟踪的文件
normal- 显示未跟踪的文件和目录
all- 还显示未跟踪目录中的单个文件。
可以使用git-config [1]中记录的status.showUntrackedFiles配置变量来更改默认值。
-v --verbose
显示HEAD提交与提交消息模板底部提交的内容之间的统一差异，以帮助用户通过提醒提交具有哪些更改来描述提交。请注意，此差异输出的前面没有前缀#。这个差异不会是提交消息的一部分。请参阅commit.verbosegit-config [1]中的配置变量。
如果指定了两次，则另外显示将提交的内容和工作文件之间的统一差异，即对被跟踪文件的未分离更改。
-q --quiet
Suppress commit summary message.
--dry-run
不要创建提交，而是显示要提交的路径列表，包含未提交的本地更改的路径以及未跟踪的路径。
--status
使用编辑器准备提交消息时，在提交消息模板中包含git-status [1]的输出。默认为打开，但可用于覆盖配置变量commit.status。
--no-status
使用编辑器准备默认提交消息时，不要在提交消息模板中包含git-status [1]的输出。
-S<keyid> --gpg-sign=<keyid>
GPG标志提交keyid参数是可选的，并且默认为提交者身份; 如果指定，它必须粘贴到选项没有空格。
--no-gpg-sign
commit.gpgSign设置为强制每个提交进行签名的计数器配置变量。
--
不要将更多的参数解释为选项。
<file>…
当在命令行上给出文件时，命令将提交指定文件的内容，而不记录已经执行的更改。这些文件的内容也将在下一次提交之前进行演示。
日期格式
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字符。
Note | In addition, the date part is accepted in the following formats: YYYY.MM.DD, MM/DD/YYYY and DD.MM.YYYY. |
|---|
例子
在录制自己的作品时，工作树中修改文件的内容将临时存储到一个名为“index”的临时区域中git add。一个文件只能在索引中恢复，但不能在工作树中git reset HEAD -- <file>恢复为最后一次提交的文件，这会有效地恢复git add并阻止对该文件的更改参与下一次提交。在使用这些命令构建要逐步提交的状态之后，git commit（不带任何路径名参数）用于记录迄今为止已执行的操作。这是命令的最基本形式。一个例子：
$ edit hello.c $ git rm goodbye.c $ git add hello.c $ git commit
不要在每个单独更改之后登台文件，而是git commit要注意对在工作树中跟踪内容的文件进行更改，git add并git rm为您做相应的工作。也就是说，如果工作树中没有其他更改，则此示例与前面的示例执行的操作相同：
$ edit hello.c $ rm goodbye.c $ git commit -a
命令git commit -a首先查看您的工作树，注意到您修改了hello.c并删除了goodbye.c，并执行了必要的操作git add并git rm为您执行。
在更改许多文件之后，您可以通过提供路径名来更改记录更改的顺序git commit。当给出路径名时，命令进行提交，只记录对指定路径所做的更改：
$ edit hello.c hello.h $ git add hello.c hello.h $ edit Makefile $ git commit Makefile
这使得提交记录修改Makefile。所做的更改已进行hello.c并且hello.h未包含在结果提交中。然而，他们的变化并没有失去 - 他们仍然上演，只是被阻止。在上述顺序之后，如果你这样做：
$ git commit
第二次提交会记录更改hello.c并按hello.h预期进行。
合并后（由git mergeor 发起git pull）由于冲突而停止，干净合并的路径已经分阶段为您提交，并且发生冲突的路径处于未合并状态。您必须首先检查哪些路径与git status您的工作树中的手动修复冲突，然后像往常一样分阶段执行结果git add：
$ git status | grep unmerged unmerged: hello.c $ edit 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等等，但是
notUTF-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]。
Hooks
这个命令可以运行commit-msg，prepare-commit-msg，pre-commit，post-commit和post-rewritehooks。有关更多信息，请参阅githooks [5]。
文件
$GIT_DIR/COMMIT_EDITMSG
文件包含正在进行的提交的提交消息。如果git commit在创建提交之前由于错误而退出，则用户提供的任何提交消息（例如，在编辑器会话中）将在此文件中可用，但将在下一次调用时被覆盖git commit。