我仍然不完全清楚git提交消息应该写的方式。
我知道基本规则，但这个让我困惑。在我的练习项目中，我创建了一个登录系统和一个用户注册，但尚未在数据库中实现安全密码存储。他们仍然以纯文本形式存储索尼风格。我想在提交消息中记下这一点，但我发现自己陷入了一个奇怪的困境，即如何在命令式中表达这一点。
有什么想法吗？
我个人认为，这应该包含在提交消息中，即使它是对提交中未包含的内容的声明，因为它代表了任何希望使用可能不明显的代码的人的重要信息。瞥一眼这些变化。
关于提交消息的一篇好文章是How to Write a Git Commit Message。
它的规则n°5确实推荐using imperative mood。
命令听起来有点粗鲁;这就是为什么我们不经常使用它。但它非常适合git commit主题行。 这样做的一个原因是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提交消息应该写的方式。
该主题没有单一的权威机构。我的建议是不要为此流泪。做对你感觉合适的事。如果有人抱怨，请他们详细解释你做错了什么，并尝试学习。 （请记住，有些人永远不会满意。）
提交消息不应包含当前变更集中尚未实现的事项的注释。相反，它应该;
提交消息告诉我们通过给定提交将什么添加到源代码中。提交消息表示将在代码上应用的更改集。
许多专家给出的指南for example this article which提到了一个摘要行，然后是一个空白行，然后是对提交消息的描述。
要遵循的命令式情绪规则仅适用于提交消息的第一个摘要行。提交消息的摘要行只应提及如果将此提交应用于代码将进行的更改。将其写为命令性句子是合乎逻辑的。
要提及的其他内容可以始终是提交消息描述的一部分，您可以在其中写一两段，其中包括未实现的内容。编写Git commit是为了记录git commit将添加的更改。其他架构决策和信息更适合其他文档，如架构决策注册，产品路线图，产品开发维基。如果提交消息中仍然需要其他信息，则应将其添加到消息的描述中。