清理常规提交

说实话，Git 确实很麻烦。它就像冷燕麦片一样让人兴奋。然而，如果使用得当，它可以节省数百万美元™。

5 项提交的健全性检查

提交频率越高，跟踪更改的效果就越好，并且能够在需要时恢复。频繁提交的小提交可以轻松合并，且不会产生冲突。这就像保存游戏一样，只是效果更好。

原子很小，你的提交也应该如此。不要把 8 小时的工作塞进一个提交里。原子性也应该适用于你的提交。提交中的所有内容都应该相互关联。这样你就可以轻松回滚，而无需撤消不相关的更改。

搬家时最不想遇到的是什么？标签错误的箱子或标签错误的箱子。提交应该以命令式的方式书写。提交应该描述他们做了什么，而不是他们做了什么。

Git 的设计允许在仓库的每个克隆版本之间共享完整的更改“账本”。项目的完整历史记录保存在每台机器上。因此，不要让提交停留在本地机器上。如果您有远程仓库，请将代码发布到其他地方。您永远不知道您的笔记本电脑什么时候会缓存起来、出现自我意识，或者更糟的情况。

Git 为您提供“王国的钥匙”，并允许您对代码库进行任意数量的破坏性操作。我见过错误的合并操作导致数月的工作因一次错误操作而化为乌有。因此，请将您的提交视为不可变的。一旦写入，它们将永远被封存。如果您需要进行更改，请还原提交并进行适当的更改。

由于 Git 为您提供了充分的自由来为您的分支和提交命名，因此对于如何编写这些提交标签有一个通用的约定是一个好主意。

这是td;lr （摘要）

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

是的，提交可以是多行的，并且像电子邮件一样编写。然而，99％的时间，您将专注于第一行。

<type>[optional scope]: <description>

我知道你在想什么……

幸运的是，有一些工具可以帮助这个过程顺利进行。

这些对提交进行分类，并告诉你这是哪种类型的更改。以下是一些示例：

范围允许您将提交限制到应用程序的特定功能、文件或子集中。

fix(Navigation): change Loggin to Login

chore(deps): upgrade Jest to v24.5.7

就像电子邮件的正文一样，如果您想在提交中添加更多描述，您可以在第一行下方进行添加。

注意：如果提交包含重大更改，则会将其放入提交主体中。

feat(Authentication): update cipher for better security

 BREAKING CHANGE all security keys will need to be regenerated and deployed.

页脚是可选的，用于在提交中引用工单，而不会堵塞提交主题行。页脚遵循特定格式：

...“每个页脚必须由一个单词标记组成，后跟一个：或#分隔符，再后跟一个字符串值。”
常规提交

有几种工具可以解析提交消息并自动创建指向票证的链接。

refactor(Header): correct minor typos in code

see the issue for details

Refs: JIRA-9999

就像你已经发布了产品一样继续操作。通常有人，即使是你的软件开发者同事，也在使用你的软件。他们会想知道哪些问题得到了修复，哪些地方出现了问题等等。

可以使用任何大小写，但最好保持一致。

尽管通常情况下使用的是小写字母。

尽可能地返回并进行多次提交。常规提交的好处之一在于它能够促使我们进行更有条理的提交和 PR。

它不鼓励以混乱的方式快速推进。它可以帮助你在多个项目中与不同的贡献者长期快速推进。