问题标签 [conventional-commits]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
github - 用于非 JS 项目的常规提交工具
有没有办法在非节点/非 npm/非 js 项目中强制执行常规提交？（除了预提交钩子，因为它们很容易被覆盖）
semantic-release - 语义释放中断更改使用！（感叹号）
可以使用感叹号在语义发布中处理主要版本更改（又称重大更改）吗？
传统的提交指南表明，可以在页脚中使用页眉中的感叹号标记重大更改。
这是我一直在测试的工作流程
设置存储库 ✓</h2>
删除单个文件并将其称为新功能✓</h2>
现在使用页脚消息进行重大更改✓</h2>
这不能按预期工作
这不能按预期工作
到目前为止看起来不错 ✓</h2>
现在尝试使用 ! 感叹号 ✗ :( :( :(
尝试自定义配置
我使用了“@semantic-release/commit-analyzer”（角度）的默认预设，并尝试了自定义预设（conventionalcommits）
查看源代码
当我查看源代码时，它看起来像是应该支持标头中的重大更改。
javascript - Semver 次要和补丁数字更新逻辑
master我正在编写一个脚本，该脚本根据和current分支之间的提交差异来提升包版本。我conventional commits用来决定要更新哪个号码。
假设我默认有1.0.0
BREAKING CHANGE:更新主要+1，即使有其他一些变化，其他数字也保持不变，所以我得到2.0.0feat:更新次要 +1，我们会得到1.1.0fix:更新补丁 +1，并为我们提供1.0.1
关于这种版本控制方法，我有几个问题：
current如果我在分支上有多个提交，feat:或者fix:我应该根据这些提交的数量升级次要/补丁版本还是应该只是 +1 ？
例如，分支上有3 个提交，当我合并分支时，版本应该是1.4.0还是只是1.1.0？feat:currentmaster
fix:如果我已经数过了，我应该数数feat:吗？
例如有1 feat:和1 fix:，合并时master版本应该变成1.1.1还是1.1.0？
github-actions - 带有 github 操作的 lerna 常规版本控制
我已经设置了 github 操作以在 PR 上针对development和main. 然后在工作流程中我有一个任务如下：
基本上是发布一个 beta 版本，然后development在 PR 反对该分支时发布，同时从最后一个 beta 版本毕业并从mainPR 反对main分支时发布。这很好用，除非在使 beta 版本毕业时development保持其最后一个 beta 版本，同时main升级到毕业的生产版本（例如development是 1.0.1-beta.0main而是 1.0.1）。CHANGELOG.mdBeta版毕业时的内容也有所不同。这种行为会导致main和development不同步，因为CHANGELOG.md和生产版本main永远不会传播到development分支中。你如何解决这个问题？
主意
每次 beta 毕业后main重新合并。development这与git潮流背道而驰。
这是lerna.json：