[Conventional Commits为提交消息定义了几种类型，例如feat，fix，chore，ci等
我的问题是有关工作流程是否跨越几天工作的功能的工作流程。作为一名优秀的开发人员，我想尽早且经常提交，但“常规提交”意义上的功能定义为：
feat：类型为feat的提交将新功能引入到代码库（这与语义版本控制中的MINOR相关）。
因此，这种类型的提交只能使用一次（否则，从这些提交生成的CHANGELOG将列出许多功能，这些功能实际上只是特定功能的一部分）。
我想知道什么是常见的工作流程来解决提早提交（和推送）并经常使用常规提交的问题？
每个人都将其提交压缩为feat: ...类型的提交吗？还有其他工作流程吗？
在挤压feat之前使用哪种类型的消息？
是。好吧，我知道。实际上，我使用two分支私下处理一项功能。其中一个是功能分支，稍后我将推送进行拉取审核。另一个是我经常保存的临时工作分支。我不时地将南瓜从温度合并到特征的末端。因此，临时文件有30次提交，但功能有2次或3次提交。在您的情况下，这听起来像您希望它只有1次提交！
还请记住，您可以修改，交互式地变基/压缩，重置等，以在第一次推送分支之前重写您的分支。这样，您就不需要两个分支。您可以使用一个分支进行早期保存，并且经常保存，然后在推送之前完全重写您的历史记录。
When提交与标准Git工作流程无关，因为提交是本地的，因此在发布之前可以修改（并且
应该修改它们，请参见下文）。
每个人都将自己的提交压缩为一项壮举：...类型提交吗？还有其他工作流程吗？
那里有很多工作流程，但并非都很好。例如，将所有提交压缩为一个并留下临时/“ WIP”提交都是错误的方法。委员会应该是一段时间内的独立工作单元。如果可以将您的功能分为5个各自有意义的提交，则应该这样做。关键是要使它们尽可能易于理解，并尽可能地可恢复。这就是为什么如果功能足够大，将所有内容压缩到一个提交中就无法进行评论的原因。以类似的方式，留下临时或WIP提交对您的日志和未来研究毫无用处。
我建议您看看Git项目本身以及Linux内核（为其创建的项目）是如何做到的。