git commit消息是否应该提及已修改的文件？

50

在git commit消息的第一行中，我习惯性地提到如果更改不涉及多个文件，则修改的文件，例如：

Add [somefunc] to [somefile]

这是一件好事还是没有必要？

git

— 马蒂
source

84

版本控制工具功能强大，足以使用户看到修改了哪些文件以及添加了哪些方法。这意味着，通常，简单地复制已经存在的日志消息正在污染日志。

您添加somefunc了满足要求的方法，即：

添加功能
删除错误或
重构源代码。

这意味着您的日志消息必须更确切地说明哪些功能/错误受到了影响或重构的目的是什么。

— 阿森尼·莫尔琴科（Arseni Mourzenko）
source

5

还应该说说为什么。您还考虑了哪些其他选择，为什么选择了这一选择？

— 杰伊·巴祖兹

2

我对提交的注释与我对代码的注释相同，只是从更高的角度（即，信息少，摘要多）。就我个人而言，我将其分解为文件/模块级别（以git为单位），但这只是因为前期的提交很便宜，而且我喜欢能够像一本书一样阅读历史记录。YMMV。

— Evan Plaice 2012年

1

如果由于某种原因该人员一次提交了与同一错误无关的一堆文件，我希望他们在总结之前列出文件名和错误ID。我不需要知道file.cpp：添加了getMethod（），但是我想要错误ID＃10 file.cpp：这里的体面夏日。如果他们确实提交了分散在多个错误报告中的一堆文件，我们将进行讨论，因为我不是很喜欢。我宁愿他们进行多次提交。他们要解决的每个问题之一。

— 威廉

@William：另外，如果一个错误修复有问题，可以以最小的代价恢复它。在一次提交中结合十个错误修复程序，这可能是一个严重的问题。

— David Thornley，2012年

59

否。有很多方法可以检查提交的内容。注释应描述提交的目的。

— 丹·雷
source

30

不要忘了添加票号/问题号。

如果您具有任何带有故障单＃或问题＃的功能或问题跟踪系统，请确保将该ID＃放入提交中。这将帮助想要了解有关您正在使用的功能或问题的更多信息的任何人。

在我的上一个项目中，开发了一个宏，以确保注释的前7位数字是明确任务（我们的问题/功能跟踪系统）中的有效问题编号。

— java_mouse
source

那么，您如何进行重构更改？

— Jules

@Jules重构有一张票永远不会结束

— Caleth

@Jules一种方法是将重构作为“杂务”类问题进行跟踪，因此它也具有问题号。

— Scott McIntyre

@ScottMcIntyre虽然这可能是正确的，但我不认为这是个好主意。重构通常是最佳时机执行的，或者作为依赖于要重构的代码的开发过程的一部分。正如Fowler 所说，“计划中的重构是团队没有使用其他工作流程进行足够的重构的标志”。或更直接地由罗恩·杰弗里斯（Ron Jeffries）：重构-不在积压中！。

— 2013年

3

当我提交例如需要修复多个文件的缺陷的修复程序时，我会做这种事情。这使得在不查看变更集中的单个文件的情况下更容易分辨出实际更改。

对于单个文件变更集，这是不必要的。

第一行始终是变更集的高级描述，例如指向缺陷或用户故事的链接。

— 迈克·帕特里奇
source

3

如果在提交消息的叙述中有相关信息，则可以，将其包括在内。如果信息的唯一部分是文件名本身，则否。

例如，这很有意义：“将build_foo（）函数从fooutil.c移动到foobase.c，因为大多数要使用build_foo（）的程序已经包含foobase.c”。

这不是：“已将fooutil.c中的build_foo（）更新为带有bar参数。”

— 安迪·莱斯特（Andy Lester）
source

1

我想在这里添加一个不同的观点。

我的回答是“是”或“否”。但是通常我会说“是”。

版本控制确实足够强大，可以知道要更新哪个文件。但是，当我们这样做时

$ git log

我们只会看到提交消息。那是大多数人所做的。

通过查看日志本身。它为其添加了其他上下文。例如：

readme.md: Fix typo detected by language tool

胜过

Fix typo detected by language tool

但是，如果更改产生了多个文件，则至少要提及正在编辑的组件。

API: Fix reset password not sent email to user

通过阅读它，我们知道已解决的错误是在API组件上，并且很可能在代码库的API目录下。

但是我们可以做

$ git show COMMIT_ID --name-only

但它增加了更多的步骤来获取文件。

— 亚娜·阿贡·西斯万托（Yana Agun Siswanto）
source

0

我唯一看到这对单个文件签入有用的唯一情况是，是否对文件中许多位置使用的函数进行了更改，导致diff混乱。即使这样，我也要先放置变更跟踪器＃和该变更的纯文本描述。

— 丹·尼利
source

-1

我认为真正的问题是您的提交范围有多有限？如果您等待一次提交中提交各种不相关的更改，那么您可能会感到需要指定出于什么目的更改了哪些文件。

但是，如果您只是更频繁地进行更狭窄的提交，则一次提交将说明修改了哪些文件，并且您可以简单地描述消息的目的。

更多提交，更频繁。这样一来，您就可以避免在消息中如此冗长。

— 拉菲
source

-2

不应该

每个感兴趣的人都可以看到历史的变化

在大型系统中也不可行，因为可能会自动生成许多文件

— CodeART
source