功能完成前的提交类型答案

【问题标题】：Commit type before feature is done功能完成前的提交类型
【发布时间】：2020-07-29 15:09:39
【问题描述】：

Conventional Commits 为提交消息定义了几种类型，例如feat、fix、chore、ci 等。

我的问题是关于工作流程的，如果我正在开发一个范围跨越数天工作的功能。作为一名优秀的开发人员，我想尽早并经常提交，但常规提交意义上的功能被定义为：

feat：feat 类型的提交为代码库（这与语义版本控制中的 MINOR 相关）。

所以这种类型的提交只能使用一次（否则，从这些提交生成的CHANGELOG 会列出许多实际上只是特定功能的一部分的功能）。

我想知道早期解决提交（和推送）并经常使用常规提交的常见工作流程是什么？

是否每个人都将他们的提交压缩为 feat: ... 类型的提交？还有其他工作流程吗？

在压缩feat 提交之前使用哪种类型的消息？

【问题讨论】：

【解决方案1】：

是否每个人都将他们的提交压缩成一个壮举：......输入提交？

是的。好吧，我愿意。实际上，我使用 two 分支私下开发一项功能。一个是我稍后将推动拉取审查的功能分支。另一个是我经常保存的临时工作分支。每隔一段时间，我就会从临时压缩合并到功能的末尾。所以临时有 30 次提交，但功能有 2 或 3 次。在你的情况下，听起来你希望它只有一个！

还请记住，您可以修改、交互式地变基/压缩、重置等，以在第一次推送之前重写您的分支。所以你并不真的需要两个分支；您可以使用您的一个分支来尽早并经常保存，然后在推送之前完全重写您的历史记录。

【讨论】：

【解决方案2】：

您应该只担心进行原子提交。

原子提交是一组可自行发布的更改。这需要大量的纪律，但投资回报率是巨大的：

Conventional Commits 规范不规定工作流程，它是提交消息的规范，工具可用于自动化流程：例如生成更改日志和更新包版本。

还值得注意的是，压缩不相关的提交完全违背了首先使用常规提交规范的意义。

想象一下，您必须实现一个注销按钮，顺便说一下，所有按钮现在都大了几个像素，这带来了重大变化。你实际上有两个工作：

如果您将这两个不相关的变更集压缩到一个提交中，您将面临在次要版本中发布重大变更的风险。

如果您最终不需要使这些按钮变大怎么办？如果你没有压缩这两个提交，你可以简单地恢复第一个提交。

当您处理一项任务时，您可能最终会在修复错误或实现某个功能之前创建一些重构提交，这并非不可能。也许不再需要修复或功能，但您的重构提交是否属于这种情况？无论修复或功能如何，这些都可能是您实际需要的有价值的更改。

没有充分的理由压缩不相关的提交。您最好继续修改代码库中的第一个也是唯一一个提交，但您不会这样做。

【讨论】：

【解决方案3】：

作为一名优秀的开发人员，我希望尽早并经常提交

那是“尽早并经常发布/发布”，而不是提交。当您的提交与标准 Git 工作流程无关，因为提交是本地的，所以在您发布之前可以修改它们（您应该修改它们，见下文）。

是否每个人都将他们的提交压缩成一个壮举：......输入提交？还有其他工作流程吗？

那里有许多工作流程，但并非所有工作流程都很好。例如，将所有提交压缩为一个并保留临时/“WIP”提交都是错误的方法。

随着时间的推移，提交应该是独立的工作单元。如果您的功能可以分成 5 个提交，每个提交都有意义，那么您应该这样做。关键是要使它们尽可能易于理解，并且尽可能可恢复。

这就是为什么如果功能足够大，将所有内容压缩到一个提交中会使评论变得不可能。以类似的方式，留下临时或 WIP 提交对您的日志和未来研究毫无用处。

我建议您看一下 Git 项目本身以及 Linux 内核（创建它的项目）是如何做到的。

【讨论】：

【解决方案4】：

我们使用短暂的功能分支。当功能分支合并回 master 时，会创建一个新版本。所以你可以做几个壮举：提交到你的功能分支。

【讨论】：