如何编写Git提交消息

柔情只为你懂 2022-12-22 00:56 102阅读 0赞

## 引子 ##

[\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-SLxuYTaP-1605590867089)(https://images.fengjiaheng.top/images/20190628/01.png “01”)\]][img-SLxuYTaP-1605590867089_https_images.fengjiaheng.top_images_20190628_01.png _01]

### 为什么好的 `Git Message` 很重要 ###

如果你去随机浏览任何一个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 kernel][]和[Git itself][]就是很好的例子。看看[ Spring Boot][Spring Boot]，或者[Tim Pope][]管理的任何存储库。

这些存储库的贡献者知道，一个精心制作的Git提交消息是向其他开发人员(实际上是他们未来的自己)传达上下文变更的最佳方式。差异会告诉您发生了什么变化，但是只有提交消息才能正确地告诉您原因。 Peter Hutterer很好地说明了这一点:

> 重建一段代码的上下文是浪费。我们不能完全地避免它，所以我们应该尽可能的去减少它。`Git Messages`可以做到这一点，因此，从提交消息可以看出来一个开发者是不是一个好的团队协作者。

如果你没有考虑什么是一个好的git提交消息，可能是因为你没有花太多时间使用`git log`和相关工具。这里有一个恶性循环:因为提交历史是无组织的和不一致的，所以人们不会花太多时间使用或处理它。因为它没有被使用或处理，它仍然是无组织的和不一致的。

但是，一旦你用心维护`git log`记录，它是非常有用的。`git blame`、`revert`、`rebase`、`log`、`shortlog`和其他子命令都会被用活。经常去看一看别人的提交记录是非常值得的，并且突然可以独立完成。理解为什么几个月或几年前发生的事情变得不仅可能而且有效。

## 七条规则 ##

### 用空行将主题与正文隔开 ###

### 将主题限制在50个字符之内 ###

![02][]

![03][]

### 将主题行大写 ###

### 主题行结束时不要加句号 ###

### 在主题行中使用祈使句 ###

### 用72个字符包装正文 ###

### 用信息体解释`Why`和`How` ###

## 小贴士 ##

[img-SLxuYTaP-1605590867089_https_images.fengjiaheng.top_images_20190628_01.png _01]: https://xkcd.com/1296/
[Linux kernel]: https://github.com/torvalds/linux/commits/master
[Git itself]: https://github.com/git/git/commits/master
[Spring Boot]: https://github.com/spring-projects/spring-boot/commits/master
[Tim Pope]: https://github.com/tpope/vim-pathogen/commits/master
[02]: /images/20221120/5ef1a7aa94184a23bee8f0e89b18f291.png
[03]: /images/20221120/4e945d2a8eb84672bb7953cd183627f5.png