这就是问题所在：对于我们的50多个存储库中的每一个，我们都有一个三层分支模型：Dev，Test，Master。 开发人员可以随时更新开发人员，并且由团队负责人汇总变更并将其提交给我们的测试环境，然后将代码合并到测试分支并进行标记。一旦测试并通过（部署）代码，便将其迁移到主代码。在将代码放入master并成功部署之后，我们将杀死旧分支并仅在需要时创建新分支。
但是，我们正在使用SonarQube和Fortify扫描代码，每次请求新分支时更新扫描计划都变得不知所措。我们希望保留每个版本都刷新分支的模型。
我的想法是为每个存储库创建一个新分支，该分支始终保持相同的名称，但是每次从dev分支进行合并测试时，都会自动将来自test分支的代码合并到其中。我们将使用此分支进行代码扫描，因为它应该与更改的分支完全匹配。
我们可以将其作为Jenkins管道脚本的一部分开始，但这只会将问题从“更新扫描计划中的分支”转移到“更新50多个脚本”（或一个参数化列表，更好，但不理想）
有没有一种方法可以在将主要合并合并到永久性主要测试分支的同时自动执行从dev分支到永久测试分支的合并？所有这些都无需手动更新脚本（或者更好的是，参数化列表）？我可能会遇到问题（父分支问题等）
答案 0 :(得分：2)
通常，您在此处要执行的操作是在服务器端进行的，有几种方法可以实现。
首先，如果您使用的是请求请求，则可以将要在请求请求时扫描的代码设置为CI。不通过的代码不会合并（或仅与管理员覆盖合并）。这是人们传统上处理此问题的方式，并且效果很好。您可以拥有一组所有CI作业都使用的全局脚本，这将要求您第一次更新多个脚本，而在随后的迭代中则不需要。
第二，如果您的服务器端实现支持post-receive挂钩，则可以添加此类挂钩以在推送时更新永久测试分支。这需要支持该功能的服务器端实现，而大多数情况不支持。
第三，如果您的服务器端实现支持webhook传递，则可以使用它与可以为您执行操作的服务进行对话。这将要求该服务具有某种令牌或SSH密钥才能执行该任务。
第四，如果您使用的是GitHub（云版本，而不是自托管版本），则可以选择加入GitHub Actions并使用它执行此任务。这还需要某种秘密，可以用来更新分支。