如何正确使用常规/语义提交？

问题描述

我已添加到使用semantic-release来自动提高NPM软件包版本的存储库中。回购协议使用Convention Commits specification来构造其提交。

我应该如何进行回购？ （自述文件非常有限。）

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

还是我不必担心，因为分支是chore，因此semantic-release知道将软件包打包在功能文件夹中的一个次要版本？

希望以上所述是有道理的，但如果不是这样，则是一个提交历史记录示例：

feature/ABC-123

上面的示例是否会因为我使用feat: add product card basic layout feat: add title to product card test: add unit tests to product card feat: add image to product card chore: update breakpoints for card test: add more unit tests 3次而使NPM软件包增加3个次要版本，或者仅使1个次要版本增加NPM软件包？还是这无关紧要，唯一重要的是压榨提交并确保feat是压榨的提交消息？

解决方法

您可以在dryRun mode中运行semantic-release，它会告诉您如果不实际执行该操作将会采取什么措施。

默认情况下，给定您列出的提交，它将颠覆次要版本。它基于集合中最大的变化而变化。您没有重大更改，但是有很多新功能。如果在一系列提交后运行该功能，则不会对每个功能都一次触发该版本。该场景只会碰撞一次。

据我所知，分支名称无关紧要。都是关于提交消息的。