标题不是最好的，我同意，请阅读更多细节来理解我的意思…
我有一个项目/存储库，它有以下属性:
- 提交消息遵循常规提交
- 以上结果:仓库中没有一个地方有版本号。版本会根据提交历史自动计算。
- 过去"发布"的历史记录基本是git的标签历史(当发布完成，
1.2.3版本出现时，相应的提交被标记) - CI与Github"简单"集成，每次合并/推送到master都会触发完整的管道，包括
deploy/release部分(生成新版本，推送标签，发布)。总之) - 我没有办法(或者，我认为我没有办法，或者我不想)手动触发CI以从CI本身释放。每个触发器都应该来自git/github。
虽然这在一般情况下工作得很好，但我的问题是，通常repo是恒定的，没有收到真正的新提交，然而在一些活跃的日子里，我可能有2-3-4-10个新的拉请求要合并。
使用当前的方法，10个合并的pull请求将产生10个版本和10个版本的增加。但我更喜欢首先合并所有10个和，然后有一个发布和一个版本增加。
有什么建议吗，我怎么才能做到这一点，这里最先进的建议是什么?
我的一个想法是有一些pre-release或develop分支，在那里我可以首先合并pr，只有在发布的时候，合并develop到master。但它看起来有点麻烦，并没有真正使贡献者的生活更轻松(他们需要目标开发，然后我需要创建PR从开发到主等…)
:
- 我相信，答案应该与ci无关。这里是哪个CI系统并不重要，重要的是我不想去CI触发作业，所有的交互都应该通过存储库发生。当然，repo和CI之间的Webhooks/连接是可用的并且正在工作。
- 当然，说到"简单"我并不是说它的配置是固定的。当然，我可以以任何我想要的方式更新它，没有问题(从存储库触发不同的事件，在不同的分支等)
有多种方法可以实现你的愿望。
你自己已经提到了一个想法:
我的一个想法是有一些预发布或开发分支，在那里我可以首先合并pr，只有在发布的时候，合并开发到主版本。
这是迄今为止最省力的方法。其他的一切都需要您更改管道。如果你同意的话，这里有一些想法在你目前的结构下并不难实现:
- 将管道更改为不释放
master分支中的每个更改，而释放release分支中的每个更改。这样，所有的开发人员仍然可以瞄准master，然后你可以压缩所有的提交并将它们引入release。这种方法很简单，但根据项目的不同，可能会导致git结构的问题和/或混乱。 - 将管道更改为不会在
master分支中的每个更改上发布，而是在每个推送的新标签上发布。这样，你就可以收集master分支中所有的提交，一旦你决定它准备好发布，只需手动推送一个git标签。如果您想进一步配置管道，以便仅在您(或其他受信任的维护者)签署了包含version bump to vX.Y.Z之类内容的提交消息时自动创建git标记。这种方法是一种更现代的方法，提供了更大的灵活性，但比以前的方法需要对管道进行更多的更改(请记住，更改管道是一次性的努力)。