在从Hg转移到Git的同时，我也在提交消息创作。我发现关于Git的行长度的常见建议是：
我正在使用 SourceTree 完成当前Git的大部分工作。我意识到上面的1和2只是典型的建议而不是规则。但是，无论他们的状态如何，我都想让SourceTree帮助我同时遵循这两项建议。
为此，我启用了以下设置：
☑使用固定宽度字体进行提交消息
中显示commet消息中的列指南
☑在[72]字符
然而，这仅对第一指南提供了有限的支持（主题行＆lt; 50 chars）。如果我将“72”改为“50”，我的问题就会被逆转（上面的建议2变得更难以遵循）。 在SourceTree中是否有任何方法可以改善这种情况，以便它可以帮助我两个的建议？或者当我的直觉感觉指示我做的时候，我仍然坚持计算字符数所以？
答案 0 :(得分：8)
答案 1 :(得分：1)
50个字符的推荐实际上来自git的{{1}} man页面。
这个commit页面内容为：
虽然不是必需的，但开始提交消息是一个好主意 一个短的（少于50个字符）总结变化的行， 然后是一个空白行，然后是更详尽的描述。 处理提交消息中第一个空白行的文本 作为提交标题，该标题在整个Git中使用。例如，
man（1）将提交转换为电子邮件，并使用标题 主题行和正文中其余的提交。
但在git-format-patch中的任何地方都没有提到72个字符的限制。此约定源自git终端用户，因为git不会在字边界处断开长行但只是将文本打印到屏幕，导致它在80个字符或任何宽度后自动断开你的终端是。为了获得一个好的格式，我们的想法是选择72个字符，因为提交消息缩进4个空格，如果你在结尾留下另外4个空格来获得屏幕上的对称填充，那么你有git log。
我的建议如下：
推理：
由于50/72规则很常见，许多工具（软件，Web服务等）都认为如果它们将提交消息缩短到第一个换行符或前50个字符就可以了，无论是什么第一。因此，如果您没有将任何合理的内容放入提交消息的前50个字符中，那么您将无法在这些工具中看到有用的提交消息。即使您没有使用这些工具中的任何一个，也可能会在同一个项目中工作，这将确保这些人在他们的工具中获得很好的提交消息。
至于72个字符的限制，请参阅上面的内容，这仅仅是为了在终端窗口中显示提交消息，但所有其他工具（如应用程序和Web服务）都能正确地在字边界上打破长线，所以如果你不喜欢＃39;坚持72个字符的限制，使用这些工具的人不会有任何问题，因此这个限制远远不如第一行的50个字符限制。对于终端用户来说，提交消息仍然是可读的，尽管有些丑陋的断线。
恕我直言，80 - 4 * 2 = 72开发人员的任务是修复终端中提交消息的打印，而不是使用git解决该限制的人的任务，如果终端只有40字符宽度？然后它仍然会有72个字符的丑陋休息。谁定义了终端今天的宽度必须是80个字符，因为这曾经是操作系统前UI区域中计算机的文本控制台宽度？打破单词边界上的文字并不难。