在@rasky的更新后，https://tip.golang.org/doc/contribute.html#commit_messages 有一个很好的、清晰的Go提交信息指南。https://github.com/golang/go/wiki/CommitMessage 也有一个非常类似的指南。
不幸的是，它们有一些偏差：例如，wiki提到了一个76列的限制，而contribute.html没有。
我们应该消除这种偏差：要么两个文档都列出完整的详细信息，要么其中一个提供更简洁的摘要并链接到另一个以获取详细信息。
9条答案
按热度按时间wvyml7n51#
嘿，@bcmills,我想开始贡献，并对解决这个问题感兴趣，这对你来说可以吗？
eqzww0vc2#
这将非常棒，但请与@rasky协调这些更改。
eoigrqb63#
感谢@bcmills。
我只会有一个地方提供完整的详细信息，并在需要的地方链接它。你认为对于这个文档来说，哪个更重要：维基还是golang.org?
/cc @rasky
uoifb46i4#
这是一个很好的问题 :)我不是一个合适的人选来发起这个呼叫，我没有足够的见解来了解wiki是如何诞生和演变的。事实上，整个contribute.html可以放在wiki上，原则上(或者反过来，wiki可以成为网站的html页面)。我不喜欢这个网站的一个原因是它遵循Go发布周期。等待6个月才能将更新推送到网页是不合理的：我不确定这是否是一个可以解决的问题。
也许我们应该问问@bradfitz或@spf13他们是否有关于这个问题的建议。如果我们还没有准备好就如何解决wiki与html之间的冲突发起呼叫，我认为我们可以采取保守的做法，暂时将两者对齐。那将是一个立即可执行的CL。
00jrzges5#
我已经在wiki中添加了一个指向其他页面的链接，并调整了一些文字，大约76个字符，说明我们为什么要这样说。(贡献页面已经删除了这部分内容，因为罗伯反对，但现实是许多基于网络的git提交查看工具都假设 Package 好的提交消息，所以我们只是承认这一点。)
92dk7w1h6#
我不认为这实际上解决了偏差问题：
contribute.html(它被认为比wiki更容易发现)仍然缺少与wiki相关的信息，并且仍然没有链接到它。从https://golang.org开始的贡献者仍然会得到一个格式错误的提交信息。如果将行宽限制在76列之外不是一个真正的需求，那么我们不应该在代码审查中强制执行它，也不应该在wiki中提及它。另一方面，如果它确实是一个真正的需求，那么从明显的起点(https://golang.org/project/)更容易发现它。
lnlaulya7#
@robpike,你有什么建议我们应该如何解决这个问题？
z2acfund8#
如果将换行限制在76列并非真正的需求，
就我而言，这是一个需求。
我知道Rob不喜欢使用孔明卡片和行数限制，但我会继续告诉人们用自动换行格式化他们的提交信息，这样它们在流行的工具中看起来很好，这些工具假设我们仍然生活在一个使用孔明卡片的世界里。
我会让@bcmills负责解决这个bug,但是如果有人从wiki上删除了这段文字，我将被迫浪费时间在代码审查中重复自己，重申已删除的文本，到那时，我可能会创建一个新的不可编辑的URL,说出相同的话。
ctrmrzij9#
当我第一次为golang做出贡献时，我忘记在"Fixed XXX"后面添加空行以及其他错误。之后，我为它提交了一个PR(commit 67653c4cd04edde8df483d06fb85a89843d1f306 (HEAD -> fix-contribute, tag: fix-contribute.mailed))。因此，我同意我们应该从wiki上复制这个内容。
值得注意的是，对于主题(描述的第一行):
受更改影响的包的名称在冒号前
冒号后的部分使用动词时态+完成"This change modifies Go to ________"中的空白部分的短语
冒号后的动词小写
没有尾随句号
应尽可能保持简短(许多git查看工具更喜欢在~76个字符以下，尽管Go对此并不严格)。