常规提交定义了几种类型的提交消息，如, feat,fix等。choreci
我的问题是关于工作流程，如果我正在开发一个范围跨越数天工作的功能。作为一名优秀的开发人员，我想尽早并经常提交，但常规提交意义上的功能定义为：
feat: 类型的提交为feat代码库引入了一个新特性（这与语义版本控制中的 MINOR 相关）。
所以这种类型的提交应该只使用一次（否则，CHANGELOG从这些提交中生成的 a 会列出很多特性，这些特性实际上只是特定特性的一部分）。
我想知道早期解决提交（和推送）并经常使用常规提交的常见工作流程是什么？
每个人都将他们的提交压缩为feat: ...类型提交吗？还有其他工作流程吗？
feat在压缩提交之前使用哪种类型的消息？
每个人都将他们的提交压缩成一个壮举：......输入提交？
是的。嗯，我愿意。实际上，我使用两个分支私下开发一个功能。一个是我稍后将推动拉取审查的功能分支。另一个是我经常保存的临时工作分支。每隔一段时间，我就会从临时压缩合并到功能的末尾。所以 temp 有 30 次提交，但功能有 2 或 3 个。在你的情况下，听起来你希望它只有一个！
还要记住，您可以修改、交互式地变基/压缩、重置等，以在第一次推送之前重写您的分支。所以你真的不需要两个分支；您可以使用您的一个分支来尽早并经常保存，然后在推送之前完全重写您的历史记录。
您应该只担心进行原子提交。
原子提交是一组可自行发布的更改。它需要大量的纪律，但投资回报率是巨大的：
git bisect有效地使用常规提交规范不规定工作流程，它是工具可用于自动化流程的提交消息规范：例如生成更改日志和更新包版本。
还值得注意的是，压缩不相关的提交完全违背了首先使用常规提交规范的意义。
想象一下，您必须实现一个注销按钮，顺便说一下，所有按钮现在都大了几个像素，这引入了一个重大变化。你实际上有两件工作：
如果您将这两个不相关的变更集压缩到一个提交中，您将面临在次要版本中发布重大变更的风险。
如果您最终不需要使这些按钮变大怎么办？如果你没有压缩这两个提交，你可以简单地恢复第一个提交。
当您处理一项任务时，您可能最终会在修复错误或实现功能之前创建一些重构提交，这并非不可能。也许不再需要修复或功能，但您的重构提交是否属于这种情况？无论修复或功能如何，这些都可能是您实际需要的有价值的更改。
压缩不相关的提交没有充分的理由。您最好继续修改代码库中的第一个也是唯一一个提交，但您不会这样做。
作为一名优秀的开发人员，我想尽早并经常提交
那是“尽早并经常发布/发布”，而不是提交。当您提交与标准 Git 工作流程无关时，因为提交是本地的，所以它们在您发布之前是可修改的（您应该修改它们，见下文）。
每个人都将他们的提交压缩成一个壮举：......输入提交？还有其他工作流程吗？
那里有许多工作流程，但并非所有工作流程都很好。例如，将所有提交压缩为一个并保留临时/“WIP”提交都是错误的方法。
随着时间的推移，提交应该是独立的工作单元。如果您的功能可以分成 5 个提交，每个提交都有意义，那么您应该这样做。关键是使它们尽可能易于理解，并且尽可能可恢复。
这就是为什么如果功能足够大，将所有内容压缩到单个提交中会使评论变得不可能。以类似的方式，留下临时或 WIP 提交对于您的日志和未来的研究毫无用处。
我建议您看一下 Git 项目本身以及 Linux 内核（创建它的项目）是如何做到的。
我们使用短暂的功能分支。当功能分支合并回 master 时，会创建一个新版本。所以你可以做几个壮举：提交到你的功能分支。