Git Commit消息结构

Question

我从头开始创建一个新的存储库，我想确保我正确启动。我正在与之前使用github的开发人员交谈，我想在继续开发他们的代码之前修复它。

我已经在github上做了很多阅读，我将在明天将存储库放在一起。我希望得到你对我将使用的git提交消息的格式的意见，如果我做了任何不正确的事情（格式，太详细等）我的所有提交将遵循相同的格式，所以我想要正确。

此处及其中一条提交消息的示例，请提前感谢。

＆＃34;添加WIFI重新连接

添加了强制WIFI模块保存和重启的代码，如果数据包发送成功后已超过45秒。

添加此项是为了解决WIFI模块与其网络连接断开的问题。一旦断开连接，它只会尝试重新连接有限次数。

现在，如果WIFI模块断开连接或数据未正确发送45秒，将强制重启，模块将尝试连接并在唤醒时进行传输。＆＃34;

Answer 1

编写一个好的提交消息非常重要，而且你对它进行了如此多的考虑是很棒的。一般来说，经验法则是用现在时写，写出简短的描述性信息。

也许更重要的是，提交应该包含小而合乎逻辑的工作单元。在您的示例中，该提交中包含的代码可能是很多代码，可能太多了。您的示例看起来像一个很棒的合并提交，或合并/压缩提交消息。

因此，较小的提交，呈现紧张的短消息，仅在必要时使用扩展描述。

Answer 2

我通常的做法是提供最小但清晰的提交消息，以缩短历史记录。试想一下查看具有类似提交信息的文件的git日志，就像阅读本书一样。

另一方面，一些问题修复需要更多的详细说明和解释，这就是问题跟踪的来源。您可以在提交消息中提及问题编号以供参考。当您在提交消息中提供魔术短语并推送更改时，Github甚至会allows to automatically close the issue。

当然，每个开发者都有自己的风格，这个问题绝对是基于意见的。

Answer 3

因此，我决定使用您在答案和回复中给我的所有信息来回答我自己的帖子。我这样做是因为这更像是一个基于意见的问题，无法真正得到回答，我想将其关闭。

我已经决定添加更短的提交消息并在github上使用问题跟踪器（我刚刚发现，感谢大家）来保存更详细的信息。我的新提交消息格式以及我的问题开始和结束评论都在下面，以防它可能对其他人有帮助。再次感谢大家，我非常感谢所有的建议。

发布评论

WIFI模块失去与其网络的连接。一旦断开连接，它将在超时之前尝试重新连接有限次数。

发布密切评论：

添加了代码以强制WIFI模块保存并重新启动（如果数据包发送成功后已超过45秒）。无论网络连接如何，都会发生保存和重新启动。在wakup上，模块将尝试连接和传输。

提交消息：

添加WIFI重新连接

修复问题＃1。添加WIFI重新连接。如果自上次成功数据包以来超过45秒，现在会自动尝试重新连接。