常规提交为提交消息定义了几种类型，如feat、fix、chore、ci等。
我的问题是，如果我正在开发一个范围跨越几天工作的功能，那么工作流是什么问题。作为一名优秀的开发人员，我想尽早提交，但常规提交的功能定义为：
feat：类型为feat的提交为代码库(这与语义版本控制中的MINOR相关)。
因此，这种类型的提交应该只使用一次(否则，从这些提交生成的CHANGELOG将列出许多功能，这些功能实际上只是特定功能的一部分)。
我想知道早期解决提交(和推送)并经常使用常规提交的常见工作流是什么？
是否每个人都将自己的提交压缩为feat: ...类型的提交？是否有其他工作流？
在压缩feat提交之前使用哪种类型的消息？
是否每个人都将自己的提交压缩为一项壮举：。。。键入commit？
是。我知道。事实上，我私下使用两个分支来开发一个功能。一个是功能分支，我稍后将推动pull review。另一个是我经常储蓄的临时工作分支。每隔一段时间，我就会将merge从临时压缩到功能的末尾。因此，temp有30个提交，但特性有2个或3个。在你的情况下，听起来你希望它只有一个！
还要记住，在第一次推送分支之前，您可以进行修改、交互式地重新设置/挤压、重置等操作来重写分支。所以你真的不需要两个分支；您可以使用您的一个分支尽早且经常地保存，然后在推送之前完全重写您的历史记录。
您应该只担心进行原子提交。
原子提交是一组可自行发布的更改。它需要大量的纪律，但投资回报率是巨大的：
- 您可以释放或回滚到任何提交
- 你可以有效地使用
git bisect - 您可以更准确地定位和恢复不必要的更改
- 您可以有效地使用Git历史记录在代码库中查找模式
常规提交规范并没有规定工作流，它是一个提交消息的规范，工具可以使用它来自动化流程：例如，生成更改日志和移植包版本。
同样值得注意的是，压缩不相关的提交从一开始就完全违背了使用常规提交规范的意义。
想象一下，您必须实现一个注销按钮，顺便说一下，所有按钮现在都大了几个像素，这带来了一个突破性的变化。你实际上有两项工作：
- 专长：使所有按钮变大。断裂变化
- 壮举：实现注销按钮
如果将这两个不相关的变更集压缩到一个提交中，则有可能在小版本中发布破坏性的变更。
如果你最终不需要把这些按钮做得更大呢？如果您没有压缩这两个提交，您可以简单地恢复第一个提交。
在处理任务时，在修复错误或实现功能之前，您可能会创建一些重构提交，这并非不可能。也许修复或功能将不再需要，但重构提交的情况是这样的吗？无论修复或功能如何，这些都可能是您实际需要的有价值的更改。
没有充分的理由压制不相关的提交。你也可以继续修改你的代码库中的第一个也是唯一一个提交，但你不会这么做。
作为一名优秀的开发人员，我希望尽早并经常提交
这是"尽早发布"，而不是提交当提交在标准Git工作流中不相关时，因为提交是本地的，所以在发布之前它们是可修改的(您应该修改它们，见下文)。
是否每个人都将自己的承诺压缩为一项壮举：。。。键入commit？是否有其他工作流？
有很多工作流，但并非所有工作流都是好的。例如，将所有提交压缩为一个提交和保留临时/"WIP"提交都是错误的方法。
随着时间的推移，委员会应该是独立的工作单位。如果您的特性可以分为5个提交，每个提交都有意义，那么您应该这样做。重点是让它们尽可能容易理解，尽可能还原。
这就是为什么如果功能足够大，那么将所有内容压缩到一个提交中会使评论变得不可能。以类似的方式，留下临时或WIP提交对于日志和未来的研究都是无用的。
我建议你看看Git项目本身以及Linux内核(它是为之创建的项目)是如何做到这一点的
我们使用寿命短的功能分支。当要素分支合并回主控形状时，将创建一个新版本。因此，您可以完成以下几项任务：提交到您的功能分支中。