针对特定模块的git提交消息的最佳实践

Question

我们当前的项目由/modules/中的多个模块组成。当我处理当前模块并更新其README时，应该如何编写一条提交消息呢？

1. Update README
2. Update README in module_XYZ
3. Update README [module_XYZ]
4. module_XYZ | Update README
5. 还有别的吗？

我认为1.信息太少了，因为单个模块的结构都是相似的，因此这将是模棱两可的。2-4似乎更好，但这意味着我总是需要将模块名添加到提交消息中，这在某种程度上是多余的，因为实际提交显示了哪个模块(文件)受到了影响。

我读过这篇不错的如何编写Git提交消息文章，但没有提到如何编写提交影响的模块。

Answer 1

当您键入git commit，编辑器弹出时，将会有许多注释行，如：

# modified: foo/bar/baz.py
# modified: foo/bar/quix.py

我倾向于简单地取消对这些行的注释，并添加更改后的注释(我倾向于喜欢非常冗长的提交消息，主要是为了简化代码评审)。因此，我最后得到了类似于以下内容的提交消息：

[ISSUE-XXXX] Refactored SomeClass to conform to internal team stile guide

modified: foo/bar/baz.py
- split bigMethod of SomeClass into smallMethod and tinyMethod
- added docstring to undocumentedMethod
- removed extra whitespace

Answer 2

我通常对特定的任务使用相同的提交消息，这样以后我就可以使用git命令找到用于该任务的文件名。

例如，我的任务是"#Task1“

对于这个任务，我对每个提交都使用"#Task1“消息。

但是，您不能添加在此"#Task1“下不受影响的其他文件。

Answer 3

我开始添加模块名作为前缀，后面跟着冒号。这就是为什么：

• 该模块描述消息的“上下文”，因此将其放在消息的前面是有意义的。
• 由于我使用的是常见的"hist“别名，所以"..。”语法已经呈现给作者。
• 使用冒号是一个很好的视觉分隔符，并与“常见电子邮件惯例”对齐，以便用冒号分隔前缀(例如"Fwd：..")。在冒号后面用大写字开头也是正常的，所以最佳实践仍然受到尊重。

结果：

* abc1234 2018-10-02 | my-module: Update readme [rudi]
* 1234560 2018-10-01 | other-module: Update readme [rudi]
* 123b123 2018-10-01 | Apply new formating rules [rudi]