在 SourceTree 中将提交消息主题保持在 50 个字符以下
Keep commit message subject under 50 characters in SourceTree
在从 Hg 迁移到 Git 的同时，我也在复习提交消息的编写。我发现关于 Git 行长度的常见建议是：
- 第一行/主题行最多 50 个字符；
- 后续行最多 72 个字符。
我目前的大部分 Git 工作都在使用 SourceTree。我意识到上面的 1 和 2 只是典型的 建议 而不是 规则 。但是，无论它们的状态如何，我都想让 SourceTree 帮助我同时遵循这两个建议。
为此，我启用了以下设置：
☑ Use fixed-width font for commit messages
☑ Display a column guide in commet message at [72] characters
但是，这仅对第一条指南提供有限的支持（主题行 < 50 个字符）。如果我将“72”更改为“50”，我的问题就会逆转（并且上面的建议 2 变得更难遵循）。 SourceTree 中有什么方法可以改善这种情况，以便它可以帮助我解决两个 条建议吗？直觉告诉我这样做？
据我所知，遗憾的是，没有。
它在 Sourcetree 的 Jira 系统中注册为次要优先级的改进：
50 个字符的建议实际上来自 git man 页面 commit。
此 man 页面内容如下：
Though not required, it's a good idea to begin the commit message with
a single short (less than 50 character) line summarizing the change,
followed by a blank line and then a more thorough description.
The text up to the first blank line in a commit message is treated
as the commit title, and that title is used throughout Git. For example,
git-format-patch(1) turns a commit into email, and it uses the title on
the Subject line and the rest of the commit in the body.
但是 git 中的任何地方都没有提到 72 个字符的限制。此约定起源于 git 终端用户，因为 git log 不会在单词边界处打断长行，而是继续将文本打印到屏幕上，导致它在 80 个字符或您的终端的任何宽度后自动打断是。为了获得良好的格式，我们的想法是选择 72 个字符，因为提交消息缩进了 4 个空格，如果您在末尾留下另外 4 个空格以在屏幕上获得对称填充，则您有 80 - 4 * 2 = 72.
我的建议如下：
- 将限制设置为 50，这样您就可以将第一行保持在 50 个字符以下。
- 忽略连续行的 72 个字符限制。
推理：
由于 50/72 规则非常普遍，许多工具（软件、Web 服务等）假设将提交消息缩短到第一个换行符或前 50 个字符是可以的，先来的。因此，如果您没有在提交消息的前 50 个字符中加入任何合理的内容，您将不会在这些工具中看到有用的提交消息。即使您不使用这些工具中的任何一个，从事同一项目的其他一些人也可能会使用，这将确保这些人在他们的工具中获得良好的提交消息。
至于 72 个字符的限制，见上文，这只是为了在终端中显示提交消息 window，但所有其他工具（如应用程序和 Web 服务）都可以正确且很好地打破 word 上的长行边界，所以如果你不遵守 72 个字符的限制，使用这些工具中的任何一个的人都不会遇到任何问题，因此这个限制远没有第一行的 50 个字符限制那么重要。对于终端用户，提交消息仍然是可读的，尽管换行有点难看。
恕我直言，git 开发人员的任务是修复终端中提交消息的打印，而不是使用 git 的人的任务来解决该限制，如果终端有只有 40 个字符宽度？然后它仍然会使用 72 个字符进行难看的中断。今天谁规定终端必须是 80 个字符宽，只是因为这曾经是 UI 操作系统之前区域计算机的文本控制台宽度？在单词边界上打破文本并不难。
在从 Hg 迁移到 Git 的同时，我也在复习提交消息的编写。我发现关于 Git 行长度的常见建议是：
- 第一行/主题行最多 50 个字符；
- 后续行最多 72 个字符。
我目前的大部分 Git 工作都在使用 SourceTree。我意识到上面的 1 和 2 只是典型的 建议 而不是 规则 。但是，无论它们的状态如何，我都想让 SourceTree 帮助我同时遵循这两个建议。
为此，我启用了以下设置：
☑ Use fixed-width font for commit messages
☑ Display a column guide in commet message at [72] characters
但是，这仅对第一条指南提供有限的支持（主题行 < 50 个字符）。如果我将“72”更改为“50”，我的问题就会逆转（并且上面的建议 2 变得更难遵循）。 SourceTree 中有什么方法可以改善这种情况，以便它可以帮助我解决两个 条建议吗？直觉告诉我这样做？
据我所知，遗憾的是，没有。
它在 Sourcetree 的 Jira 系统中注册为次要优先级的改进：
50 个字符的建议实际上来自 git man 页面 commit。
此 man 页面内容如下：
Though not required, it's a good idea to begin the commit message with a single short (less than 50 character) line summarizing the change, followed by a blank line and then a more thorough description. The text up to the first blank line in a commit message is treated as the commit title, and that title is used throughout Git. For example,
git-format-patch(1) turns a commit into email, and it uses the title on the Subject line and the rest of the commit in the body.
但是 git 中的任何地方都没有提到 72 个字符的限制。此约定起源于 git 终端用户，因为 git log 不会在单词边界处打断长行，而是继续将文本打印到屏幕上，导致它在 80 个字符或您的终端的任何宽度后自动打断是。为了获得良好的格式，我们的想法是选择 72 个字符，因为提交消息缩进了 4 个空格，如果您在末尾留下另外 4 个空格以在屏幕上获得对称填充，则您有 80 - 4 * 2 = 72.
我的建议如下：
- 将限制设置为 50，这样您就可以将第一行保持在 50 个字符以下。
- 忽略连续行的 72 个字符限制。
推理：
由于 50/72 规则非常普遍，许多工具（软件、Web 服务等）假设将提交消息缩短到第一个换行符或前 50 个字符是可以的，先来的。因此，如果您没有在提交消息的前 50 个字符中加入任何合理的内容，您将不会在这些工具中看到有用的提交消息。即使您不使用这些工具中的任何一个，从事同一项目的其他一些人也可能会使用，这将确保这些人在他们的工具中获得良好的提交消息。
至于 72 个字符的限制，见上文，这只是为了在终端中显示提交消息 window，但所有其他工具（如应用程序和 Web 服务）都可以正确且很好地打破 word 上的长行边界，所以如果你不遵守 72 个字符的限制，使用这些工具中的任何一个的人都不会遇到任何问题，因此这个限制远没有第一行的 50 个字符限制那么重要。对于终端用户，提交消息仍然是可读的，尽管换行有点难看。
恕我直言，git 开发人员的任务是修复终端中提交消息的打印，而不是使用 git 的人的任务来解决该限制，如果终端有只有 40 个字符宽度？然后它仍然会使用 72 个字符进行难看的中断。今天谁规定终端必须是 80 个字符宽，只是因为这曾经是 UI 操作系统之前区域计算机的文本控制台宽度？在单词边界上打破文本并不难。