问题标签 [conventional-commits]

语义版本控制提交消息有chore什么用？其他类型如专长或修复很清楚，但我不知道何时使用“杂务”。

谁能提供几个使用它的例子？

另一个可能不相关的问题：修改文件的正确提交消息类型是.gitignore什么？

Lerna 似乎无法根据Conventional Commits 规范3.20.2来提升预发布版本（例如） 。1.0.0-alpha.0

如果您想尝试一下，我制作了一个最小可重现示例。

假设我们有两个 Lerna 管理的存储库，它们都有三个子包。一个仓库有“生产”包，另一个有“预发布”包：

然后我在两个存储库中进行以下提交：（提交遵循常规提交规范）

• 主要包中的重大变化
• 次要包中的新功能
• 补丁包中的错误修复

并在两个存储库中运行此命令：

观察

“生产” repo 看到它的包根据 Conventional Commits 规范更新：

然而，在预发布 repo 中，所有包都只是“打补丁”：

这个 GitHub问题中的线程似乎表明这是一个错误（但我不确定）。

问题我希望我的“预发布”存储库中的软件包以与“生产”存储库中相同的方式进行更新，同时保留它们的预发布后缀。我在这里做错了什么？

你也可以跟进我提出的这个 GitHub问题

常规提交定义了几种类型的提交消息，如, feat,fix等。choreci

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

feat: 类型的提交为feat代码库引入了一个新特性（这与语义版本控制中的 MINOR 相关）。

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

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

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

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

我正在尝试适应本文中描述的常规提交消息。

这是文章的一个片段：

允许<type>值：

但有时有一些变化很难归类为这种类型。我将列出一些更改，其中 w/ci 对使用哪种类型感到困惑

在这种情况下我应该使用什么类型

1. 我在现有组件上添加了一个 CSS 样式（反应、角度、vue 等）
2. 我在我的项目中编辑了配置文件，例如package.json，.prettierc等。
3. 重命名文件
4. 删除文件

使用 GitLab

收到以下错误消息。

要遵循的解决方案。

我正在尝试在我的 javascript 项目中使用标准版本。我将release脚本添加到我的 package.json 中：

我的问题是我向我的 git repo 添加了一个提交，并带有以下消息：

我运行npm run release它，它增加了项目的补丁版本。

所以我的初始版本是0.2.1（标签：v0.2.1），我0.2.2用这个提交消息生成

为什么不增加次要版本？

我正在使用 lerna.js 开发 monorepo。为了生成 GHANGELOG.md，我使用conventional-commits. Conventional-commits 在 lerna 中是 biult 所以很容易使用命令来升级版本lerna version --conventional-commits。

但问题是：我将我的项目存储在 Bitbucket 上，当通过 Bitbucket Web 界面合并时，Bitbucket 会提供自动生成的提交消息。它以“合并”开头。

由于它不符合conventional-commits（根据其规则，提交消息必须以“fix:”或“chore:”之类的内容开头）的要求，因此这些提交不包含在 CHANGELOG.md 中。这里有什么快速的解决方案？

更新 我想知道是否有一些工具可以在不使用的情况下为 lerna 生成更改日志conventional-commits？有没有人遇到过这样的问题？

基于传统的提交，应该如何对单纯的 UI 更改进行分类？例如，假设注销按钮从屏幕底部移动到顶部，在文本旁边添加了一个图标，并且有一个新动画。除此之外，从功能的角度来看没有任何变化。

我的困惑来自这个（可能是错误的）推理。您不能使用以下任何一项，因为：

• 壮举：这不是一个新功能
• 修复：没有要修复的错误
• perf：性能未触及
• 重构：这可能是遵循Angular对重构的定义“既不修复错误也不添加功能的代码更改”，但不使用Wikipedia对重构的定义“代码重构是重构现有计算机代码的过程——改变因式分解——不改变其外部行为”
• 样式：不影响代码含义的更改（空格、格式、缺少分号等）。不言而喻，事实并非如此

我已被添加到一个使用语义发布来自动提升 NPM 包版本的存储库中。该 repo 使用Conventional Commits 规范，并且 README 非常有限。

如果我要创建一个feature/ABC-123包含新功能的分支，这是否意味着我所做的每一次提交都应该有一个提交结构，feat: my message related to this commit或者我应该只有一个feat提交，其余的chore或其他类型不会增加 repo 的版本?

或者我不需要担心这个分支feature/ABC-123，因此语义发布知道将包提升 1 个次要版本，因为它位于功能文件夹中？

希望以上内容有意义，但如果不是，这里是一个提交历史示例：

上面的这个例子会将 NPM 包提升 3 个次要版本，因为我已经使用了feat3 次，或者一个它只提升了 1 个次要版本？还是这无关紧要，唯一重要的是压缩提交并确保feat: added product card例如压缩的提交消息？

遵循常规提交<type>对于包版本更改（升级/更新）的提交来说，什么是最好的？

例如：feat: Bump React version to "16.13.1"

例如：feat: Upgrade all dependencies