blocks|key|2213216|text|写一条好的提交信息是很重要的，而且你花了这么多心思去写它是很棒的。一般来说，经验法则是用现在时写，写简短的、描述性的信息。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2213217|也许更重要的是，提交应该包含小的、逻辑的工作单元。在您的示例中，提交中包含的代码可能是大量的代码，可能太多了。您的示例看起来像是一个很棒的合并提交，或者合并/压缩提交消息。|2213218|因此，较小的提交、当前时态短消息，只在必要时使用扩展描述。|2213219|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Writing a good commit message is important, and it's fantastic you're putting so much thought into it. In general, the rule of thumb is to write in present tense and to write short, descriptive messages.

Maybe more importantly, commits should hold small and logical units of work. It appears in your example that the code encompassed in that commit could be a lot of code, maybe too much. Your example looks like a great merge commit, or merge/squash commit message.

So, smaller commits, present tense short messages, only use the extended description when necessary.

blocks|key|293387|text|我通常的做法是提供最少而清晰的提交消息，以缩短历史。想象一下，查看具有与您的提交消息相似的文件的git日志，就像阅读这本书一样。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|293388|另一方面，一些问题的修复需要更多的阐述和解释，这就是问题跟踪的地方。您可以在提交消息中提及问题号以供参考。当您在提交消息中提供神奇短语并推动更改时，Github甚至是允许自动关闭问题。。|offset|length|293389|当然，每个开发人员都有自己的风格，这个问题绝对是基于意见的。|293390|entityMap|0|LINK|mutability|MUTABLE|url|https://help.github.com/articles/closing-issues-via-commit-messages/^0|0|2B|9|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@$D|R|E|S|1|T]]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

My usual practice is to have minimal yet clear commit messages, to make history short. Just imagine looking over the git log of a file that has similar commit messages to yours, it's like reading the book.

On the other hand, some problem fixes needs more elaboration and explanations, that's where issue tracking comes in. You can mention the issue number in commit message for a reference. Github even <a href="https://help.github.com/articles/closing-issues-via-commit-messages/" rel="nofollow">allows to automatically close the issue</a> when you provide the magic phrase in commit message and push the change.

Of course, every developer has it's own style, and this question is absolutely opinion-based.

blocks|key|2213321|text|所以我决定用你们在回答和回复中给我的信息来回复我自己的帖子。我这么做是因为这更多的是一个基于观点的问题，不能得到真正的回答，我想关闭它。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2213322|我已经决定我将添加更短的提交消息，并使用github上的问题跟踪器(我刚刚发现，感谢大家)来保存更详细的信息。我的新提交消息格式以及我的问题、开始和结束评论都在下面，以防对其他人有帮助。再次感谢各位，我真的很感谢你们的建议。|2213323|发行评论：|offset|length|style|BOLD|2213324|WIFI模块失去与其网络的连接。一旦断开，它将尝试重新连接有限的次数，然后超时。|2213325|发布贴切评论：|2213326|添加代码，以强制WIFI模块保存和重新启动，如果它已经超过45秒，因为一个包已成功发送。无论网络连接如何，都会发生保存和重新启动。唤醒后，模块将尝试连接和传输。|2213327|提交消息：|2213328|添加WIFI重新连接|2213329|修复问题#1.添加WIFI重新连接。如果上次成功数据包后超过45秒，现在自动尝试重新连接。|2213330|entityMap^0|0|0|0|5|0|0|0|7|0|0|0|5|0|0|0^^$0|@$1|2|3|4|5|6|7|X|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Y|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|Z|8|@$F|10|G|11|H|I]]|9|@]|A|$]]|$1|J|3|K|5|6|7|12|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|13|8|@$F|14|G|15|H|I]]|9|@]|A|$]]|$1|N|3|O|5|6|7|16|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|17|8|@$F|18|G|19|H|I]]|9|@]|A|$]]|$1|R|3|S|5|6|7|1A|8|@]|9|@]|A|$]]|$1|T|3|U|5|6|7|1B|8|@]|9|@]|A|$]]|$1|V|3|-4|5|6|7|1C|8|@]|9|@]|A|$]]]|W|$]]

So I have decided to answer my own post using the information that all you guys have given me in your answers and replies. I am doing this because this is more of an opinion based question that can't really be answered and I would like to close it off. 

I have decided that I will be adding much shorter commit messages and using the issues tracker on github (which I just discovered, thanks to you all) to hold the more detailed information. My new format for commit messages along with my issues opening and closing comments are below in case it might help someone else. Thanks again guys, I really appreciate all the advise. 

Issue comment: 

WIFI module loses connection to its network. Once disconnected it will try to reconnect a limited number of times before timing out.

Issue close comment: 

Added code to force WIFI module to save and reboot if it has been over 45 seconds since a packet has been sent successfully. The save and reboot will occur regardless of network connection. On wakup the module will attempt to connect and transmit.

Commit message:

Add WIFI reconnect 

Fix issue #1. Adds WIFI Reconnect. Now automatically attempts a reconnect if over 45 seconds since last successful packet.

I am starting a new repository from scratch and I want to ensure I start off correctly. I am talking over from a previous developer who used github terribly and I want to fix it before I continue developing on to of their code. 

I have done a lot of reading on github and I will be putting the repository together tomorrow. I was hoping to get your opinions on the format of the git commit message I will be using and if I am doing anything incorrect (format, too detailed etc) All my commits will be following the same format so I want to get it right.

Here's and example of one of my commit messages, thanks in advance.

"Add WIFI reconnect 

Added code to force WIFI module to save and reboot if it has been over 45 seconds since a packet has been sent successfully.

This was added to fix an issue where the WIFI module lost connection to it’s network. Once disconnected it would only try to reconnect a limited number of times.

Now if the WIFI module disconnects or data has not been sent correctly for 45 seconds, a reboot will be forced and the module will try to connect and transmit on wakeup."

Git Commit message structure

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我正在从头开始一个新的存储库，我想确保我开始的时候是正确的。我是从以前一个非常使用github的开发人员那里谈论的，我想在继续开发他们的代码之前修复它。我已经阅读了很多关于github的文章，明天我将把存储库放在一起。我希望得到您对我将要使用的git提交消息的格式的意见，如果我做了任何不正确的事情(格式，太详细等等)，...

问Git提交消息结构
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Git提交消息结构EN