如何编写好的Git提交消息

很多新手开发人员经常忽略的一件事是他们提交消息的格式。格式正确的提交消息不仅仅是看起来整洁，还可以做更多的事情，例如：

为代码审查者提供上下文：一个好的提交消息为审查者提供关于提交实现了什么的基本信息，除非他们正在寻找细节，否则他们不需要深入研究代码。这为审查过程节省了大量时间。

帮助维护功能日志：在发布之前编写版本说明时，开发人员通常可以快速查看提交消息的历史记录，以全面了解自上次发布以来添加/删除/修改的功能。

提供知识传授：大多数项目涉及多个人/团队，从事不同的功能。每个实体通常在其本地分支上工作，它们定期与主分支一起重新建立基础。在这种情况下，通过适当的提交消息全面了解其他合作者实现的代码更改可以节省大量开发人员在交叉通信中花费的时间。

现在我们已经看到了一个好的提交消息的原因，让我们来看看它是如何实现的。在制作提交消息时，有一些要点需要牢记，如下所述。

但在其他情况下，如果您觉得提交消息太长，无法放入一行，那么可以将提交消息拆分成主题和正文。主题和正文之间用空行分隔。例如,。

将应用程序体系结构切换到MVM将有内存管理问题的组件从MVP转换到MVVM Arch。

通过这样做，您可以让其他开发人员选择查看包含详细提交消息的git日志(通过使用git log)或仅包含主题的日志(通过使用git log--Online)。

确保主题文本最多保留50个字符可以鼓励开发人员想出一种简短而简明的方式来说明他们的代码实现了什么。默认情况下，在Github中，如果提交主题文本超过50个字符，则会收到警告。在列表视图中，如果主题超过72个字符，则Github会用省略号截断结尾。因此，它被认为是一个很好的做法，目标是主题行有50个字符，同时严格控制不超过72个字符。

所有主题行都以大写字母开头，即修复图像裁剪问题，而不是修复图像裁剪问题。这往往会使您的消息在GIT日志中看起来更加整洁和统一。

将代码中的每次提交视为应用于代码库的更改。代码中的每个提交都用于应用更改。很少有例子是。

用上述语气写的句子被称为祈使语气(现在时态)。这与我们写信息的方式不同，我们称之为指示性语气(过去时)。相应的例子有。

Git提交最好用命令性语气编写，因为默认情况下，Git使用命令性语气来报告其操作。例如，看看git merge master、git add index.html、git merge Branch 1等命令。即使在Github中执行的操作也是以命令性语气编写的，例如，来自user1/user1Branch的合并拉请求#10。

请记住，此命令性语气规则仅适用于提交消息的主题。你可以随意使用身体中的任何时态。