我仍然不完全清楚 git 提交消息应该如何编写。
我知道基本规则，但这个让我感到困惑。在我的实践项目中，我创建了一个登录系统和一个用户注册，但尚未在数据库中实现安全密码存储。它们仍然以纯文本形式存储索尼风格。我想在提交消息中记下这一点，但我发现自己陷入了一个奇怪的困境，即如何在命令式中表达这一点。
有什么想法吗？
我个人确实认为，这应该包含在提交消息中，即使它是提交中未包含内容的声明，因为它对于希望使用代码的任何人来说都代表了重要的信息，通过浏览更改可能不明显。
关于提交消息的一篇好文章是 如何编写 Git 提交消息。
它的规则 n° 5 确实建议使用命令式情绪。
命令式听起来有点粗鲁;这就是为什么我们不经常使用它。但它非常适合 git 提交主题行。
其中一个原因是 git 本身在代表您创建提交时使用命令式。
就您的主题而言，一个简单的"不添加 xxx"足以完成提交的第一部分（命令式中的"积极陈述"）。
我假设您正在尝试决定是否
Don't add hashing #1
或
Didn't add hashing #2a
Doesn't add hashing #2b
势在必行。 这真的是一个英语语法问题。 但要回答这个问题，我们首先需要将宫缩恢复到它们的完整形式：
Do not add hashing #1
(It) did not add hashing #2a
(It) does not add hashing #2b
其中第一个是指令或命令...告诉人们不要添加哈希。 这是当务之急。
后两个是关于提交的简单事实陈述。 他们说提交没有或没有添加哈希。 这不是对任何人的指示或命令，因此不是必需的。 （"没有"或"没有"都是正确的。 这取决于您是在撰写信息的人还是阅读它的人的时间范围内解释消息。
通过这种分析，#1 和 #2 表单在提交消息中显然意味着非常不同的东西。 你的提交消息应该说出你的实际意思，比它们应该符合一些风格规则或约定要重要得多。
然而。。。
我仍然不完全清楚 git 提交消息应该如何编写。
在这个问题上没有单一的权威。 我的建议是不要为此流泪。 做你觉得正确的事。 如果人们抱怨，请他们详细解释你做错了什么，并尝试学习。 （请记住，有些人永远不会满意。
提交消息告诉我们通过给定提交添加到源代码中的内容。提交消息表示将应用于代码的更改集。
许多专家给出的准则，例如本文，其中提到有一个摘要行，然后是一个空白行，然后是提交消息的描述。
要遵循的命令性情绪规则仅适用于提交消息的第一摘要行。 提交消息的此摘要行应仅提及将此提交应用于代码时将执行的更改。 写成祈使句是合乎逻辑的。
要提到的其他内容始终可以成为提交消息描述的一部分，您可以在那里写一两段提及任何内容，包括未实现的内容。 Git 提交是为了记录该 git 提交将添加哪些更改而编写的。 其他架构决策和信息更适合其他文档，如架构决策寄存器、产品路线图、产品开发 wiki。 如果提交消息中仍需要其他信息，则应将其添加到消息的描述中。
提交消息不应包含当前变更集中未实现的事项的注释。相反，它应该要么;
- 简要总结更改本身（例如创建登录系统），或;
- 描述首先提示更改的任务（例如，允许用户登录）