问题标签 [conventional-changelog]

在我的 Angular 项目中，我想@commitlint/config-conventional用一些预定义的scopes.

Angular 项目有一个UI 组件库（通过 生成ng generate library）和一个使用 UI 库的默认应用程序。

在commitlint.config.js我添加了以下几行：

但是，当我尝试使用范围提交某些内容时'ui-components/tooltip'：

fix(ui-components/tooltip): fix border

我收到一个提交错误，说：

作为我的 CI/CD 管道工作流程的一部分，我正在考虑利用常规提交在 github 中自动生成发布草稿。创建草稿的想法是允许代码所有者在发布之前查看发布说明。

但是，我担心这是否会导致以下两个问题：

1. 如果我们继续将每个提交消息创建为常规提交，我们最终会得到一个巨大的更改日志，作为发布草案中的断开信息，这需要在发布之前手动重构以使其具有任何意义
2. 我可以想到的替代方法是在所有相关更改完成之前避免提交更改，并在完成后将所有相关更改推送到单个提交消息下。然而，这与 CI/CD 的提议背道而驰，因为它会延迟早期的合并

作为上述问题的解决方案，我正在考虑仅在功能完成后向主线创建拉取请求时才使用常规提交。这样我可以避免发布草案中的所有噪音，同时自动创建发布说明。但我不太确定这是否是正确的方法。我想知道其他人正在采用什么策略来处理这个问题，以及我打算采取的方法是否正确？或者如果我们最好手动创建发行说明？谢谢！

我正在使用标准版本来创建变更日志。我有一个错误生成的更改日志，因为我在运行时没有本地的所有标签standard-version --release-as minor。它最终在 2 个版本而不是 1 个版本之间进行了更改。更改日志如下所示：

自 1.6.0 以来我做了一些更改，并希望发布 1.7.0。

从远程存储库中提取所有标签并standard-version --release-as minor再次运行后，旧更改v1.4.0...v1.6.0保持不变，我得到一个新条目：

最后一次更改没有问题，但我想编辑更改日志，因此我最终不会得到一个包含来自两个不同版本的更改的版本。我以为我可以找到一种仅在两个单独的标签之间生成更改的方法，但我不确定该怎么做。

可以使用感叹号在语义发布中处理主要版本更改（又称重大更改）吗？

传统的提交指南表明，可以在页脚中使用页眉中的感叹号标记重大更改。

这是我一直在测试的工作流程

设置存储库 ✓</h2>

删除单个文件并将其称为新功能✓</h2>

现在使用页脚消息进行重大更改✓</h2>

这不能按预期工作

到目前为止看起来不错 ✓</h2>

现在尝试使用 ! 感叹号 ✗ :( :( :(

尝试自定义配置

我使用了“@semantic-release/commit-analyzer”（角度）的默认预设，并尝试了自定义预设（conventionalcommits）

我的 .releaserc

查看源代码

当我查看源代码时，它看起来像是应该支持标头中的重大更改。

我正在使用lerna version私有 gitlab 存储库，CHANGELOG.MD发布后我将在 npm 上可见，但用户无法访问提交链接，因此我想完全删除提交链接。一种方法是添加--no-push选项，撤消提交，然后手动删除链接。另一个选项与第一个选项相同，但使用 bash 脚本，它将自动删除链接。

我想知道是否可以仅使用lerna version配置来完成相同的操作？在 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：