共计 6655 个字符，预计需要花费 17 分钟才能阅读完成。
为什么好的提交信息很重要？
如果你轻易浏览一下 Git 仓库的日志，你可能会发现它的提交信息或多或少都是一团糟，例如，看看我晚期提交 Spring 的时候的这些提交：
$ git log --oneline -5 --author cbeams --before "Fri Mar 26 2009"
e5f4b49 Re-adding ConfigurationPostProcessorTests after its brief removal in r814. @Ignore-ing the testCglibClassesAreLoadedJustInTimeForEnhancement() method as it turns out this was one of the culprits in the recent build breakage. The classloader hacking causes subtle downstream effects, breaking unrelated tests. The test method is still useful, but should only be run on a manual basis to ensure CGLIB is not prematurely classloaded, and should not be run as part of the automated build.
2db0f12 fixed two build-breaking issues: + reverted ClassMetadataReadingVisitor to revision 794 + eliminated ConfigurationPostProcessorTests until further investigation determines why it causes downstream tests to fail (such as the seemingly unrelated ClassPathXmlApplicationContextTests)
147709f Tweaks to package-info.java files
22b25e0 Consolidated Util and MutableAnnotationUtils classes into existing AsmUtils
7f96f57 polishing将其与同一存仓库中中最近的提交进行比拟：
$ git log --oneline -5 --author pwebb --before "Sat Aug 30 2014"
5ba3db6 Fix failing CompositePropertySourceTests
84564a0 Rework @PropertySource early parsing logic
e142fd1 Add tests for ImportSelector meta-data
887815f Update docbook dependency and generate epub
ac8326d Polish mockito usage你更违心读哪个？
前者在长度和模式上各不相同；后者则是扼要而统一的，前者是默认状况下产生的；后者永远不会偶尔产生。尽管许多仓库的日志看起来像前者，但也有例外。Linux 内核就是很好的例子。看看 Spring Boot，或者 Tim Pope 治理的任何仓库，这些仓库的贡献者都晓得，精心设计的 Git 提交信息是向其余开发者（甚至是将来的本人）传播变动的最好形式。差别会通知你有什么变动，但只有提交信息能力正确地通知你起因。Peter Hutterer 很好地阐明了这一点。
从新建设一段代码的上下文是节约的。咱们不能完全避免它，所以咱们的致力应该去尽可能地缩小它提交信息正好能够做到这一点，因而，提交信息能够显示出一个开发者是否是一个好的合作者。
如果你没有思考过怎样才能写出一条好的 Git 提交信息，那可能是你没有花太多工夫应用 git log 和相干工具。这里有一个恶性循环：因为提交历史是无序的、不统一的，所以人们不会花很多工夫去应用或关照它。又因为它没有被应用或关照，所以它依然是非结构化的和不统一的。
git blame、revert、rebase、log、shortlog 和其余子命令都是如此。审查他人的提交和拉动申请成为值得做的事件，而且忽然能够独立实现。理解几个月或几年前产生的事件的起因不仅是可能的，而且是无效的。
一个我的项目的长期胜利取决于它的可维护性，而维护者没有什么工具比他的我的项目日志更弱小。值得花工夫去学习如何正确地保护它。一开始可能会很麻烦，但很快就会成为习惯，并最终成为所有参与者的自豪和生产力的起源。
在这篇文章中，我只探讨了放弃衰弱的提交历史的最基本要素：如何编写集体提交信息。还有其余一些重要的做法，比方提交压抑，我在这里就不谈了。兴许我会在当前的文章中探讨这个问题。
大多数编程语言对于什么是习惯性格调，即命名、格局等等，都有既定的约定。当然，这些常规也有变动，但大多数开发者都批准，抉择一个常规并坚持下去，要比每个人都做本人的事件时产生的凌乱好得多。
一个团队对其提交日志的解决形式也应该如此。为了创立一个有用的订正历史，团队应该首先约定一个提交信息的常规，至多要定义以下三点。
格调，标记语法、包边、语法、大小写、标点符号。把这些货色写进去，打消猜想，并使之尽可能的简略。最终的后果将是一个十分统一的日志，它不仅是一个浏览的乐趣，而且实际上常常被浏览。
内容，提交信息的注释（如果有的话）应该蕴含什么样的信息？不应该蕴含哪些内容？
元数据。应该如何援用问题追踪 ID、拉动申请编号等？
侥幸的是，对于怎样才能成为一条标准的 Git 提交信息，曾经有了成熟的约定。事实上，其中很多都是在某些 Git 命令的运作形式中假设的。你不须要从新创造什么。只有依照上面的办法，你就能像专家一样提交了。
优良的 Git 提交信息的七个规定
请牢记
用大概 50 个字符或更少的文字来概括变动
如有必要，提供更具体的解释文字。把它包起来，大概 72 个字符左右。在某些状况下，第一行被视为
的主题，其余部分作为注释。摘要和注释之间的摘要和注释之间的空行是十分重要的（除非你齐全省略注释）。
除非你齐全省略注释）；各种工具，如 log、shortlog、rebase 等，都会在提交过程中呈现问题。
和 “rebase “ 等各种工具，如果你把这两者放在一起运行，就会产生混同。
解释这次提交所要解决的问题。重点是为什么
而不是如何扭转（代码会解释）。这个改变是否有副作用或其余不直观的结果？的副作用或其余不直观的结果？这里就能够解释了。空行之后是进一步的段落。- 子弹头也是能够的
- 典型的做法是用连字符或星号来示意我的项目，后面是一个空格。后面有一个空格，两头有空行，但常规是
在此有所不同
如果你应用一个问题跟踪器，把对它们的援用放在底部。像这样：Resolves: #123
See also: #456, #789用空行将主体与注释离开
尽管不是必须的，但在提交信息的结尾，最好用一行简短的（少于 50 个字符）来概述该批改，而后是空白行，再来一个更详尽的形容。提交信息中第一个空行之前的文字被视为提交题目，该题目将在整个 Git 中应用。例如，Git-format-patch(1)把提交变成了电子邮件，它在主题行应用题目，在注释中应用提交的其余内容。
首先，不是每个提交都须要主题和注释。有时只需一行就能够了，特地是当变动非常简单，不须要进一步的上下文。比如说：
修改用户指南介绍中的错别字
没有什么好说的了；如果读者想晓得是什么错字，她能够间接看一下批改自身，即用 git show 或 git diff 或 git log -p。
如果您在命令行上提交这样的货色，很容易应用 git commit 的 - m 选项。
git commit -m”F 修改用户指南介绍中的错别字 ”
然而，当一个提交须要解释和阐明时，你须要写一个注释。比如说。
主控制程序 Derezz
这个承诺将 Tron 的光盘扔进了 MCP（导致其崩溃）。
并把它从新变成一个棋局。
用 - m 选项写带注释的提交信息并不那么容易。你最好用一个适合的文本编辑器来写信息。如果你还没有在命令行上为 Git 设置编辑器，请浏览 Pro Git 的这一部分。
无论如何，在浏览日志时，将主题和注释离开是有益处的。上面是残缺的日志条目。
$ git log
commit 42e769bdf4894310333942ffc5a15151222a87be
Author: Kevin Flynn <kevin@flynnsarcade.com>
Date: Fri Jan 01 00:00:00 1982 -0200
主控制程序 Derezz
这个承诺将 Tron 的光盘扔进了 MCP（导致其崩溃）。并把它从新变成一个棋局。而当初 git log –oneline，只打印出主题行。
$ git log --oneline
42e769 Derezz the master control program
42e769 Derezz 的主控程序或者，git shortlog，它按用户分组提交，同样只显示主题行，以达到简洁的成果。
$ git shortlog
Kevin Flynn (1):
Derezz 的主控程序
Alan Bradley (1):
引入平安程序 "Tron"
Ed Dillinger (3):
将国际象棋程序更名为 "MCP"
批改国际象棋程序
降级国际象棋程序Walter Gibbs (1):
介绍原版的国际象棋程序
在 Git 中，还有许多其余状况下，主题行和注释之间的区别开始发挥作用，但如果没有两头的空行，它们都不能失常工作。将主题行限度在 50 个字符以内
50 个字符不是一个硬性限度，只是一个教训法令。将主题行放弃在这个长度，能够确保它们的可读性，并迫使作者思考一下用最简洁的形式来解释产生了什么事。提醒：如果你很难进行总结，你可能一次提交了太多的批改。争取实现原子提交（这是一个独自的帖子的主题）。GitHub 的用户界面齐全理解这些常规。如果你超过了 50 个字符的限度，它就会正告你。并会用省略号截断任何超过 72 个字符的主题行。因而，争取管制在 50 个字符以内，但要思考到 72 个是硬性限度。在主题栏中应用大写字母
这和它听起来一样简略。所有主题行都以大写字母结尾。比如说。Accelerate to 88 miles per hour
Instead of:
而不是:
accelerate to 88 miles per hour
不要以句号完结主题行
在主题行中，尾部标点符号是不必要的。此外，当你试图把它们放弃在 50 个字符或更少时，空间是很贵重的。例子。Open the pod bay doors
Instead of:
而不是:
Open the pod bay doors.
在主题行中应用祈使语气
祈使语气只是意味着“像收回命令或指令一样说或写”。举几个例子。清扫你的房间
关好门
* 把垃圾倒掉
你当初读到的七条规定中的每一条都是用命令式写的（”在 72 个字符处包住身材”，等等）。命令式听起来有点粗鲁；这就是为什么咱们不常常应用它。但它很适宜用于 Git 提交的主题行。其中一个起因是，当 Git 代表你创立一个提交时，它自身就会应用该命令。例如，应用 git merge 时创立的默认信息是这样的
Merge branch 'myfeature'
而在应用 git revert 时。Revert "Add the thing with the stuff"
This reverts commit cc87791524aedd593cff5a74532befe7ab69ce9d.
或者在点击 GitHub 拉动申请的“合并“按钮时。Merge pull request #123 from someuser/somebranch因而，当你在命令式中写你的提交信息时，你是在遵循 Git 本人的内置常规。比如说
重构子系统 X 的可读性
更新入门文档
删除废除的办法
公布 1.0.0 版本
这样写一开始可能会有点难堪。咱们更习惯于用批示性语气谈话，那是对于报告事实的。这就是为什么提交的信息最初往往是这样读的。
Fixed bug with Y
Changing behavior of X
而有时提交的信息会被写成对其内容的形容。
More fixes for broken stuff
Sweet new API methods
为了打消任何纳闷，这里有一个简略的规定，能够让你每次都做得很好。
一个正确的 Git 提交主题行应该总是可能实现以下句子。
If applied, this commit will your subject line here
比如说:
如果利用，此提交将重构子系统 X 以进步可读性。
如果利用，此提交将更新入门文档
如果利用，此提交将删除废除的办法
如果利用，此提交将公布 1.0.0 版本。
如果利用，此提交将合并来自用户 / 分支的 #123 拉动申请。
请留神，这对其余非 imperative 模式是不起作用的。
如果利用，此提交将修复 Y 的谬误。
如果利用的话，此提交将扭转 X 的行为。
如果利用，此提交将修复更多破损的货色
如果利用的话，此提交将提供新的 API 办法。
请记住。祈使句的应用只在主题行中很重要。在写注释时，你能够放松这一限度。
在 72 个字符处包住文本
Git 从不主动包装文本。当你写提交信息的注释时，你必须留神它的左边距，并手动包装文本。
倡议在 72 个字符时进行，这样 Git 就有足够的空间来缩进文本，同时还能将所有内容放弃在 80 个字符以内。
一个好的文本编辑器能够帮到你。例如，配置 Vim 很容易，当你写一个 Git 提交时，它能够将文本包在 72 个字符内。然而，传统上，IDE 在为提交信息提供智能反对方面始终很蹩脚（只管在最近的版本中，IntelliJ IDEA 在这方面终于变得更好。
应用注释来解释什么和为什么与如何。
这个来自 Bitcoin Core 的提交是一个很好的例子，解释了什么变动和起因。
c`
ommit eb0b56b19017ab5c16c745e6da39c53126924ed6
Author: Pieter Wuille mailto:pieter.wuille@gmail.com
Date: Fri Aug 1 22:57:55 2014 +0200
Simplify serialize.h’s exception handling
Remove the ‘state’ and ‘exceptmask’ from serialize.h’s stream
implementations, as well as related methods.
As exceptmask always included ‘failbit’, and setstate was always
called with bits = failbit, all it did was immediately raise an
exception. Get rid of those variables, and replace the setstate
with direct exception throwing (which also removes some dead
code).
As a result, good() is never reached after a failure (there are
only 2 calls, one of which is in tests), and can just be replaced
by !eof().
fail(), clear(n) and exceptions() are just never called. Delete
them.
看看残缺的差别，想想作者花工夫在这里提供这个背景，为伙伴和将来的提交者节俭了多少工夫。如果他不这样做，可能就会永远隐没。在大多数状况下，你能够不写对于如何进行批改的细节。代码在这方面通常是不言自明的（如果代码非常复杂，须要用散文来解释，那就是源代码正文的作用）。你只需专一于分明地阐明你首先做出批改的起因—批改前的工作形式（以及其中的问题），当初的工作形式，以及你为什么决定以这样的形式来解决它。将来感激你的维护者可能就是你本人。小贴士
学会酷爱命令行。把 IDE 抛在脑后
就像 Git 的子命令一样多，拥抱命令行是理智的。Git 的性能十分弱小；IDE 也是如此，但各自的形式不同。我每天都在应用 IDE（IntelliJ IDEA），也曾宽泛应用其余 IDE（Eclipse），但我从未见过 IDE 对 Git 的整合能与命令行的便捷和弱小等量齐观（一旦你理解它）。某些与 Git 相干的 IDE 性能是十分贵重的，比方当你删除一个文件时调用 git rm，当你重命名一个文件时用 git 做正确的事件。当你开始尝试通过 IDE 提交、合并、重定位或做简单的历史剖析时，所有都会解体。要想充分发挥 Git 的威力，就得用命令行。
