Question

您对代码提交的评论使用了什么模板？

模板的一个例子是：

理想情况下，每个更改都应映射到问题跟踪器中的问题。这个模板好吗？

Answer 1

以下是我的想法......所有这些都可以根据您的特定开发方法进行解释。

您应该经常提交，每次提交只需一个焦点，因此基于此，评论应该简短并详细说明提交的重点。
我很喜欢在你的评论中发布 what ，其中为什么和在其他地方详细说明（理想情况下在你的错误跟踪）。为什么应该是机票，在关闭机票时，你应该对如何解决这个特定问题有一些注意。
如果不以其他方式处理（例如，TRAC / SVN交互），则对您的错误跟踪系统的引用是好的。这样做的原因是，如果他们正在寻找有关提交的更多信息，请指出其他开发人员正确的方向。
除非需要修复程序，否则不要包含特定的文件名。即便如此，复杂的细节可能属于使用您的实施说明进行错误跟踪，而不是版本控制。编辑的文件，差异细节等应该包含在版本控制中，我们不想花时间复制它。

鉴于这些想法，我的一个示例提交评论就像是

Req3845：更新了验证，以使用Req3831中开发的新RegEx验证。

简短，传达改变的内容，并为其他人提供某种参考，以便在不打扰你的情况下获得更多信息。

Answer 2

我在每个段落前加上+ - *或！

+ means its a new feature
- means feature is removed
* means feature is changed
! means bugfix

我认为你不应该提交有关代码的哪些部分被更改的详细描述，因为这就是每个VC都有差异的原因：）

Answer 3

如果您使用错误跟踪系统，请包含相关的票号。

您无需提及已更改的文件或您的姓名。源存储库可以自己解决这个问题。描述这些变化也只有在差异不明显的情况下才有意义。

确保你有一个好的第一行，因为这经常出现在更改历史记录视图中，并且人们需要通过此查找内容（例如，错误跟踪票号应该去那里）。

尝试在单个变更集中提交相关更改（并将不相关的更改拆分为两个提交，即使是同一个文件）。

Answer 4

我尝试遵循与代码注释相同的规则：

解释为什么，而不是 HOW 。

IMO评论应包含对问题的引用（任务跟踪器或要求）。版本控制系统已提供受影响的文件。除此之外，它应该尽可能短，但仍然可读。

Answer 5

我尝试将修复程序保存在单独的签入中。

我不使用实际模板，而是使用心理模板，就像这样。

问题 - 开发级别摘要问题。

问题跟踪器具有所有管理详细信息，并且可以检查更改/差异以查找代码更改，因此评论是供开发人员了解问题的原因/内容。

Answer 6

这是我见过的成功用法：

Answer 7

我使用Chaosben上JEDI Windows API blog描述的简单技巧。

为了快速查看   对存储库所做的更改，我们   建议写简短的简洁   评论从一行开始   这些字符：


+ 如果添加了功能/功能/ ...

- 如果您删除了功能/功能/ bug / ...

＃如果您更改了某些内容


这样做，其他开发人员可以更好地找到所需的修订版。

Answer 8

首先，提交应该解决一个单独的问题（单独提交逻辑上单独的更改）。如果您不知道在提交消息中写什么，或者comit消息太长，则可能意味着您在提交中有多个独立更改，并且您应该将其拆分为更小的项。

我认为 git 预期和使用的提交消息约定非常有意义：

Answer 9

请记住，如果有人需要更改内容的详细信息，他们可以获得差异。也就是说，我通常只是为每次重大修改写一两句话，然后在最后修改任何小修正。

Answer 10

普通英语没有严格的规则。我试着用最少的话来解释所做的工作。任何寻找变化历史的人都只想知道特定变化中发生了什么。如果有人关注更多细节，那么它就在代码中。

我遵循的第二件事是，如果有任何关联的错误，那么坚持或如果它与任何开发任务相关，然后将其与更改相关联。

Answer 11

如果两个文件由于不同的原因而被更改，则它们应该在不同的提交中每次只提交多个代码文件是因为它们都属于相同的修复/更改