与Jenkins、Gerrit和子模块的持续集成工作流 假设我们有一个C++项目，它由一个库和一个可执行文件组成。我希望将每个库都保存在自己的git存储库中，以便其他项目可以使用该库。我一直在研究将gerrit与git子模块一起使用的合理工作流程

我读过，所以我计划使用此功能自动让超级项目中的主分支在子模块中包含主分支中最新提交的更改。这提供了哪个子模块提交与超级项目提交关联的历史记录，这就是我考虑子模块而不是repo的原因

一旦超级项目订阅了子模块中的更改，最好的工作流程似乎是永远不要让开发人员更新推送到gerrit的更改中的子模块引用，而是依靠订阅来更新超级项目中的子模块引用。但是，这意味着持续集成预提交测试不知道需要对子模块进行更改，因此在提交子模块中的更改之前，无法验证依赖于子模块的任何更改

如果开发人员在其超级项目更改中更新了子模块引用，则持续集成可以正常工作，但还存在其他问题：

我已将gerrit配置为使用一个

Cherry pick

，因为我喜欢在上查看

：

链接返回提交消息中gerrit的更改。这允许我们通过查看gerrit更改上的每个补丁集来进行一些事后错误分析。但是，这会在提交时创建不同的提交，因此超级项目更改的子模块引用中指定的提交只是一个补丁集，而不是提交的更改

如果同时审查具有子模块依赖关系的多个更改，则很难处理合并冲突，因为只有第一个更改可以提交，后续更改将由于子模块基础已更改而产生合并冲突

---

是否有人建议通过消除上述痛点来改进此工作流？

如果更改具有子模块依赖性，开发人员是否可以在更改超级项目之前等待提交子模块更改？@MarceloÁviladeOliveira，在某些情况下，无法等待。例如，我可能需要同时更改子项目和超级项目，以避免打破超级项目中的基线。例如，如果我需要对超级项目和子模块之间的接口进行更改，那么这些更改需要一起提交。+1。我正在为同样的问题而挣扎。Gerrit或任何其他多项目预提交CI设置似乎都会出现此问题。BitBucket似乎用相同的命名分支解决了这一问题，但这迫使您在每个问题的每个回购中执行1个拉取请求。也不那么优雅。在Gerrit中，您可以使用主题并强制将它们一起提交，但正如您所指出的，CI不知道要签出以验证什么。另外，您可能希望使用“始终重设基础”提交类型，该类型与“Cherry Pick”具有相同的优点，但适用于依赖性更改，即解决您的第二点。