我是我的朋友，几天前我讨论了使用版本控制系统时提交消息的大小。当他另一方面使用更大的提交消息时，我有了经常和小的提交的想法，而不是经常提交。
我一直听说你应该，至少作为一个初学者，我应该这样做;经常提交小提交消息。如果可能的话，您应该用一句话来概括您的提交。
但是当我看到像Linus Torvalds这样的专业人士时，我会产生相反的感觉。这是他在github上的subsurface项目中提交的一条提交消息。
如果它们在半个范围内，则认为它们是相同的 彼此的酒吧。如果您手动编辑压力并将其设置为 与样品相同的棒压，它们可能不一样 最后毫米，但显然手动输入的气缸压力不是 与样本数据有显着差异，因此请将其视为多余 我们确实希望手动覆盖气缸压力优先 超过样本数据（正如Dirk雄辩地说的那样，一些潜水电脑 真的没有非常可靠的样本数据），但同时也是如此 样本数据是我们期望相当准确的数据。该 当没有样品时，开始和结束压力覆盖 数据，或由于某种原因样本数据完全错误 签名：Linus Torvalds
Here是有问题的提交消息。
我看了一下我自己的提交信息（我有几千个），而且通常总是少于40个字符。
任何人都对这个问题有所了解？
答案 0 :(得分：2)
提交消息的大小几乎没有与您应该提交的频率有关。
关于提交频率的一般共识是提交通常更好，但是你应该只提交有效的代码（或者至少编译并且不会破坏任何东西）。
请注意，git允许您将多个提交“压缩”为一个提交，这样您就可以获得经常提交的好处（任何时候都没有多次未提交的更改）并且只提交完整的功能（更容易理解提交历史记录）。
至于提交消息，更多信息总是好的，但当然应该与它所需的努力进行权衡。
提交消息的目的是简要概述已更改的内容（以便您在查看提交历史记录时可以决定它是否对您有意义），并解释为什么提交中的更改已完成。 Linus的信息非常详细。但是如果问题/错误跟踪系统或设计文档中有相应的条目，那么最好参考它。
答案 1 :(得分：2)
您需要考虑提交消息的受众。
如果你是唯一一个对你的项目感兴趣的人，那就尽量少写 - 你只需要提醒自己为什么你从现在开始选择另一种方法。当你想要寻找漏洞时，你需要足够的时间来找到哪个特定的提交改变了哪个特定的功能。
如果您正在为可能为数十或数百人提供服务的团队编写软件，那么提交消息应该更有意义。 （这并不总是意味着更长，但它确实意味着“修复愚蠢的bug”应该不惜一切代价避免 - “不要超出堆栈缓冲区'名称'”要好得多，几乎快速输入。）
Linus的提交消息可能看起来很大，但他不是详细或罗嗦。他简明扼要，直截了当。他正在为数千或数百万程序员，分发程序包，以及您找到的特定提交消息撰写，潜水员依赖于他的生活代码。他们想要比MMORPG签到要求更好的提交消息。
答案 2 :(得分：1)
我更喜欢使用原子提交的较小提交消息。做出小而简洁的变化。他们不需要太多解释。编写代码，如果需要解释，请让评论进行讨论。用巨大的消息扫描提交很难。只要你解释发生了什么的要点，这应该足够好了。我想它确实归结为个人偏好。
答案 3 :(得分：1)
我的提交大小取决于我的任务。 我尝试在一次提交中对类似的更改进因此，消息只描述我开发的功能（没有冗长乏味的故事）。
答案 4 :(得分：0)
很少，而且经常是我觉得最好的