译者序
在多年的软件开发过程中，作为许多团队的成员，与许多优秀和有经验的人一起工作，我经常观察到（并且说实话，我创建了）相同的问题-存储库中的总混乱。 每个人都以自己的风格对提交内容发表评论（当然，如果持续不断地发表评论）； 一半的评论没有用（来自“ 这是一座桥梁 ”类别），其余的一半几乎很难理解。然后有一个美好的时刻，我看到了这篇文章，在此之前我终于接触到了翻译。 只有7条简单而简短的规则，而且-看吧-查看提交的历史不仅有用，而且令人愉快。 没什么革命性的，一切都非常明显，但制定和总结起来就很好。我想指出的是，这是2014年的文章。 作者提到的一些不太相关的内容可能会失去相关性，但本文的本质根本没有。简介：为什么好的评论很重要
如果查看随机的Git存储库，则很可能会发现提交历史记录中有些混乱。 例如，从我开始提交到Spring存储库开始，看看
这些珍珠 ：
$ git log --oneline -5 --author cbeams-“ 2009年3月26日星期五”之前
e5f4b49在r814中短暂删除后，重新添加ConfigurationPostProcessorTests。 @忽略testCglibClassesAreLoadedJustInTimeForEnhancement（）方法，因为事实证明这是最近一次构建破坏的罪魁祸首之一。 类加载器被黑客入侵会导致细微的下游影响，破坏无关的测试。 该测试方法仍然有用，但是只能手动运行以确保CGLIB不会过早加载，并且不应作为自动构建的一部分运行。
2db0f12修复了两个破坏构建的问题：+将ClassMetadataReadingVisitor还原为版本794 +消除了ConfigurationPostProcessorTests，直到进一步调查确定其导致下游测试失败的原因（例如看似无关的ClassPathXmlApplicationContextTests）
147709f调整至package-info.java文件
22b25e0将Util和MutableAnnotationUtils类合并到现有的AsmUtils中
7f96f57抛光
恐怖 与同一存储库中的这些
最新提交进行比较：
$ git log --oneline -5 --author pwebb-“ 2014年8月30日星期六”之前
5ba3db6修复CompositePropertySourceTests失败的问题
84564a0返工@PropertySource早期解析逻辑
e142fd1添加针对ImportSelector元数据的测试
887815f更新docbook依赖性并生成epub
ac8326d波兰模拟用法
您会选择哪个选项？
前者的长度和样式各不相同，后者简洁明了。
第一个是自己获得的，第二个是有意识地编写的。
尽管许多存储库的提交历史记录看起来都像第一个选项，但也有例外。
Linux内核和
Git本身就是很好的例子。 看一下
Spring Boot或
Tim Pope处理的任何其他存储库。
这些项目的参与者都知道，关于提交的书面评论是向其他开发人员（以及将来对自己）
进行更改的
背景的最佳方式。 修订版之间的差异表明
发生了什么变化，但是只有注释可以清楚地说明
原因 。 彼得·哈特（Peter Hutterer）
说得很好 ：
从编码中恢复是浪费时间。 我们无法完全避免这种情况，因此我们的工作应集中在最小化这些成本上。 这就是对提交的评论。 因此，它们表明程序员在团队中是否运作良好。
如果您尚未真正想到一流的提交注释，那么您可能没有经常使用
git log和类似工具。 有一个恶性循环：由于提交的历史是非结构化的且异构的，因此他们不使用它，也不注意。 并且由于他们不使用它并且不注意，因此它仍然是非结构化和异构的。
但是，精心设计的存储库故事是一件美丽而有用的事情。
git blame ，
revert ，
rebase ，
log ，
shortlog等命令
变得生动起来 。 查看其他人的提交和请求很有意义，并且突然之间，现在不再需要他们的作者的帮助。 要了解几个月或几年前[代码中]发生了什么的原因，它不仅可能，而且很方便。
项目的长期成功（除其他因素外）取决于维护的便利性，而提交的历史记录是维护人员最强大的工具之一。 值得花时间学习如何保持秩序。 起初，这可能会带来一些不便，但随后将成为一种习惯，最终，它将成为所有参与者自豪和富有成效的工作的源泉。
本文仅涉及维护好故事的最基本组成部分，即，如何对单独的提交发表评论。 还有其他重要的事情，例如合并提交，此处未涉及。
大多数编程语言都有描述良好的，普遍接受的约定，这些约定形成了[编写代码]的独特样式，例如变量名，格式规则等。 当然，这种协议有不同的版本，但是大多数开发人员认为，当每个人都以自己的风格写作时，选择一个选项并遵循它比一团糟要好得多。
团队描述提交的方法应该完全相同。 为了使存储库的故事有用，团队必须至少就以下三点达成协议。
风格 标记语法，缩进，换行符，语法，大写字母，标点符号。 始终检查您的拼写并尽可能地容易书写。 结果，您将获得令人惊讶的完整提交历史，这不仅令人愉快阅读，而且您
会定期阅读。
内容内容 评论主体应包含（如果有的话）什么信息？ 为什么
不在那里？
元数据 我应如何参考任务ID，请求请求编号等？
幸运的是，已经有协议写出有意义的评论。 实际上，它们部分源于某些Git命令的工作方式。 您不需要重新发明轮子。 只需遵循以下
七个规则 -您将值得成为专业人士，比以往更进一步。
提交评论的七个规则
切记： 所有 这些 都 已经 在前面 说过了 。
- 用空字符串将标题与主体分开
- 将标题限制为50个字符
- 大写标题
- 不要在标题末尾加点
- 在标题中使用命令式。
- 转到正文中下一行的72个字符
- 在体内，回答关于什么以及为什么 ，而不是如何的问题
例如：
汇总少于50个字符的更改
如有必要，请在此处详细说明。 跟进
大约72个字符的换行符。 在某些情况下
评论的第一行被视为标题，所有
剩下的就是身体。 必须将一个彼此分开
空字符串（当然，如果消息中有一个正文）；
诸如log，shortlog和rebase之类的各种工具将无法理解
如果标题和正文未分开，则为您。
在此说明该提交解决的问题。 带走
更多关注您为什么进行这些更改，而不是
确切地说是如何做的（这将为您解释代码）。
是否有副作用或其他明显的副作用？
这些变化？ 如果是这样，则需要在此处进行解释。
段落由空白行分隔。
-您可以创建项目符号列表
-通常为星号或
在他们前面有一个破折号 但是有不同的协议
如果您有错误跟踪器[或项目管理系统]，
通过以下方式将任务链接放在文本的末尾：
解决：＃123
另请参阅：＃456，＃789
原来的汇总少于50个字符的更改
如有必要，提供更详细的说明文字。 将其包装到约72
个字符左右。 在某些情况下，第一行被视为
提交的主题，其余文本作为正文。 的
将摘要与正文分开的空行至关重要（除非
您完全忽略了身体）； 各种工具，例如“ log”，“ shortlog”
如果将两者一起运行，则“ rebase”和“ rebase”可能会引起混淆。
解释该提交正在解决的问题。 专注于你为什么
与方法（代码对此进行了解释）相反。
是否有副作用或其他不直观的后果
改变？ 这是解释它们的地方。
空白段之后是其他段落。
-子弹点也可以
-通常在项目符号前使用连字符或星号
用一个空格隔开，中间有空白行，但是约定
在这里变化
如果您使用问题跟踪器，请在其底部放置对它们的引用，
像这样：
解决：＃123
另请参阅：＃456，＃789
1.用空字符串将标题与主体分开
从
手册到
git commit命令：
尽管这不是必需的，但是最好用一条短行（少于50个字符）对提交进行注释，以总结所做的更改，然后是空行，然后是更详细的描述。 注释中第一个空行之前的文本被视为提交的标题，并在不同的Git命令中使用。 例如， Git-format-patch（1）将提交转换为电子邮件； 团队使用提交的标题作为信函的主题，使用其余文本作为信函的正文。
首先，并非每次提交都需要标头和正文。 有时一行就足够了，尤其是当更改很小时，不需要任何其他信息。 例如：
修复用户指南简介中的错字
说够了； 如果用户想知道已修复了哪种错字，则可以使用
git show或
git diff或
git log -p自己查看更改。
如果您使用命令行来提交类似的命令，对
git commit使用
-m选项将很方便：
$ git commit -m“修复用户指南简介中的错字”
但是，当提交值得对此情况进行一些解释和描述时，您需要将它们写在注释正文中。 例如：
取消主控制程序
MCP原来是邪恶的，并且已经打算统治世界。
此提交将Tron的光盘放入MCP（导致其解分辨率）
并将其转为国际象棋游戏。
具有
-body选项的注释不太方便编写。 为此，最好使用文本编辑器。 如果尚未配置可与Git一起使用的编辑器，请阅读
Pro Git手册的这一部分 。
在任何情况下，查看日志时，标题和正文的分隔都将得到回报。 这是完整的提交记录：
$ git日志
提交42e769bdf4894310333942ffc5a15151222a87be
作者：Kevin Flynn <kevin@flynnsarcade.com>
日期：星期五1月1日00:00:00 1982年-0200
取消主控制程序
MCP原来是邪恶的，并且已经打算统治世界。
此提交将Tron的光盘放入MCP（导致其解分辨率）
并将其转为国际象棋游戏。
这是
git log --oneline命令 ，仅显示标题行：
$ git log --oneline
42e769取消主控制程序
或
git shortlog，为简洁起见，由作者再次提交的组仅显示标题：
$ git shortlog
凯文·弗林（1）
取消主控制程序
艾伦·布拉德利（1）：
介绍安全程序“ Tron”
埃德·迪林格（3）：
将国际象棋程序重命名为“ MCP”
修改国际象棋程序
升级国际象棋程序
沃尔特·吉布斯（1）：
介绍原型国际象棋程序
在许多其他情况下，有必要区分提交的标头和正文-为此，必须将它们用空行分隔。
2.标题限制为50个字符
从技术上讲，可以超过50个字符，但不建议这样做。 标题的长度保证了其可读性，也使作者考虑了最简洁明了的措辞来描述正在发生的事情。
提示：如果您难以总结工作的结果，则可能是一次提交包含太多更改。 力争进行原子提交 （这是单独发布的主题）。
GitHub的界面显然支持这些约定。 如果您超过50个字符的限制，他会警告您：
并剪掉所有长度超过72个字符的标题，以椭圆代替：
因此，目标是50个字符，但请记住，72个字符是严格的限制。
3.大写标题
这里的一切都很简单。 大写所有标题。
例如：
相反：
4.请勿在标题末尾加点
不需要它。 此外，当我们尝试达到50个字符时，每个字符都会计数。
例如：
相反：
5.在标题中使用命令式。
祈使语气的字面意思是：表达意愿（命令，要求或建议）的动词形式。 一些例子：
您正在阅读的七个规则中的每一个都以命令式的语气写成（例如，用72个字符转到下一行）。
这种形式听起来有些粗鲁，因此并不经常使用
[英文-大约。 反式 ]。 但这是提交标头的理想选择。 原因之一是Git本身在代表您提交时使用了命令。
例如，当使用
git merge时，默认情况下将添加以下消息：
合并分支“ myfeature”
当使用
git revert时 ：
还原“用东西添加东西”
这将还原提交cc87791524aedd593cff5a74532befe7ab69ce9d。
或者，当您在GitHub的请求请求界面中单击“合并”按钮时：
合并来自someuser / somebranch的拉取请求＃123
因此，当您以命令式的心情编写自己的提交消息时，您将遵循Git本身制定的规则。 例如：
- 重构子系统X以提高可读性
- 更新入门文档
- 删除不推荐使用的方法
- 发行版本1.0.0
起初，这种方法看起来不舒服。 我们更习惯使用指示性的，这更有可能报告事实。 因此，提交消息经常是这样的：
有时标头只是描述提交的内容：
有一个简单的规则可以使您避免错误。
正确组成的提交标头应完成以下句子：例如：
- 如果应用，则此提交将重构子系统X以提高可读性
- 如果应用，则此提交将更新入门文档
- 如果应用，则此提交将删除不推荐使用的方法
- 如果应用，则此提交将发布版本1.0.0。
如果应用，则此提交将
合并来自用户/分支的拉取请求＃123确保其他非强制性动词在这里不起作用：
- 如果应用，此提交将修复Y错误
- 如果应用，则此提交将更改X的行为
- 如果应用，则此提交将针对损坏的内容进行更多修复
- 如果应用，则此提交将使用新的API方法
请记住：使用命令式仅在提交的标头中很重要。 在提交主体中，这是可选的。
6.转到正文中下一行的72个字符
Git本身不会自动安排换行符。 编辑注释正文时，应记住右边框并手动设置换行符。
建议您使用72个字符进入下一行，以便Git可以缩进并仍然适合80个字符。
一个好的文本编辑器可以帮助您。 例如，配置Vim以换行72个字符将消息写到提交非常容易。 但是，碰巧IDE在支持消息提交的智能换行符方面非常差（尽管IntelliJ IDEA的最新版本
终于在这一部分
变得更好了）。 （
大约每人-也许此刻一切都好得多了 ）。
7.在身体中，回答问题“什么”和“为什么”，而不是“如何”
来自比特币存储库的此
提交很好地说明了更改的内容和原因：
提交eb0b56b19017ab5c16c745e6da39c53126924ed6
作者：Pieter Wuille <pieter.wuille@gmail.com>
日期：2014年8月1日星期五22:57:55 +0200
简化serialize.h的异常处理
从serialize.h的流中删除“状态”和“ exceptmask”
实现以及相关方法。
因为exceptmask总是包含'failbit'，而setstate总是
用位= failbit调用，它所做的只是立即引发一个
例外。 摆脱这些变量，并替换setstate
直接抛出异常（这也消除了一些死点
代码）。
结果，在失败之后永远不会达到good（）（
仅2个通话，其中1个处于测试状态），可以替换
由！eof（）。
fail（），clear（n）和exceptions（）永远不会被调用。 删掉
他们。
查看
代码中的
更改，并考虑作者为项目的现在和将来参与者节省了多少时间，并在注释中描述了所做工作的背景。 否则，他可能会永远失去。
在大多数情况下，您可以省略有关更改方式的详细信息。 通常，代码在这种意义上可以代表自己（如果代码过于复杂以至于需要澄清，则其中会有注释）。
主要侧重于说明进行更改的原因-描述进行更改之前的情况（以及发生的情况），更改之后的情况以及为什么选择这种解决问题的特殊方式。
也许将来您会为此感到感谢！
小费
喜欢命令行。 忘记了IDE。
有很多原因-根据Git命令的数量-最大限度地使用命令行。 Git是一个非常强大的工具。 IDE-也是，但是每种都有自己的方式。 我每天都使用IntelliJ IDEA，我经常不得不与其他人打交道（例如Eclipse），但是我从来没有见过可以将Git在IDE中的集成在简单性和功能上与命令行进行比较（一旦您了解它）。
用于版本控制的IDE的某些功能简直无价之宝，例如，删除文件时自动执行git rm或重命名文件时执行其他必要的git片段。 但是，当您尝试使用IDE提交，合并，变基或对提交历史进行复杂分析时，情况会更糟。
当您需要释放Git的全部潜能时，命令行是首屈一指的。
请记住，无论您使用的是Bash，Zsh还是Powershell，都有一些
脚本可以 完成命令，从而使您免于记住所有子命令和选项的痛苦。
阅读Pro Git书
可以免费获得宏伟的
Pro Git书（
也有俄语 -大约是
Transl。 ）。 利用这个！