git - 如何通过持续部署触发发布管道？

标题不是最好的，我同意，请阅读更多细节以理解我的意思......

我有一个具有以下属性的项目/存储库：

提交消息遵循常规提交
上述结果：存储库中没有一个具有版本号的地方。版本是根据提交历史自动计算的。
过去“发布”的历史基本上是 git tags 历史（当发布完成并1.2.3出现版本时，相应的提交被标记）
CI 是“简单的”/与 Github 集成，每次合并/推送到 master 都会触发完整的管道，包括deploy/release部分（产生新版本，推送标签，简而言之“发布”）
我没有办法（或者，我认为我没有办法，或者我不想）手动触发 CI 以从 CI 本身释放。每个触发器都应该来自 git/github。

虽然这通常工作得很好，但我的问题是通常 repo 是不变的并且没有收到真正的新提交，但是在某些活跃的日子里，我可能有 2-3-4-10 个新的拉取请求要合并。

使用当前的方法，10 个合并的拉取请求将导致 10 个版本增加 10 个版本。但我更愿意先合并所有 10 个，然后再发布一个版本并增加一个版本。

任何建议，我怎样才能做到这一点，这里最先进的建议是什么？

我的一个想法是有一些pre-release或develop分支，我可以首先合并 PR，并且只有在发布时才合并develop到master. 但它看起来有点麻烦，并没有真正让贡献者的生活更轻松（他们需要以开发为目标，然后我需要创建从开发到主的 PR 等......）

更新：

我相信，答案应该是独立于 CI 的。在这里使用哪个确切的 CI 系统并不重要，重要的是我不想去 CI触发作业，所有交互都应该通过存储库进行。repo 和 CI 之间的 Webhooks/连接当然是可用的并且可以正常工作。
当然，我说过“简单”的 CI 并不是说它的配置是固定的。当然我可以以任何我想要的方式更新它，没有问题（触发来自存储库的不同事件，不同分支等）

标签： gitcontinuous-integrationreleasecontinuous-deploymentsemantic-versioning

有多种方法可以实现您的愿望。

您已经提到自己的一个想法：

我的一个想法是有一些预发布或开发分支，我可以首先合并 PR，并且只有在发布时，合并开发到 master。

这是迄今为止最省力的方法。其他一切都需要您更改管道。如果您对此感到满意，那么考虑到您当前的结构，这里有一些不难实现的想法：

将管道更改为不在分支中的每个更改上发布，master而是在分支中的每个更改上发布release。这样，所有开发人员仍然可以定位master，然后您可以压缩所有提交并将它们引入release. 这种方法很简单，但取决于项目可能会导致关于 git 结构的问题和/或混淆。
将管道更改为不在master分支中的每个更改上发布，而是在推送的每个新标签上发布。这样你就可以收集分支中的所有提交，master一旦你决定它准备好发布，只需手动推送一个 git 标签。如果您想更进一步，将管道配置为仅在您（或其他受信任的维护者）签署了包含类似version bump to vX.Y.Z. 这种方法是一种更现代的方法，并且提供了更大的灵活性，但与以前的方法相比，它需要对管道进行更多的更改（请记住，更改管道是一次性的）。