假设我们有一个C ++项目，它包含一个库和一个可执行文件。我想将每个文件保存在自己的git存储库中，以便其他项目可以使用该库。我一直在研究使用gerrit和git子模块的合理工作流程。
我读到了gerrit's ability to have a superproject subscribe to changes in a submodule，因此我计划使用此功能自动让超级项目中的主分支包含子模块中主分支中最新提交的更改。这提供了哪个子模块提交与超级项目提交相关联的历史记录，这就是我考虑子模块而不是repo的原因。
一旦超级项目订阅了子模块中的更改，似乎最好的工作流程似乎是永远不要让开发人员在推送到gerrit的更改中更新子模块引用，而是依赖订阅更新超级项目中的子模块引用。但是，这意味着持续集成预提交测试不知道需要更改子模块，因此在子模块的更改提交之前，无法验证任何依赖于子模块的更改。
如果开发人员在超级项目更改中更新子模块引用，则持续集成可以正常工作，但还有其他问题：
Cherry-pick Reviewed-on:，因为我希望将{{1}}链接返回到提交消息中gerrit的更改。这允许我们通过查看关于gerrit变化的每个补丁集来进行一些事后错误分析。但是，这会在提交时创建一个不同的提交，因此超级项目更改的子模块引用中指定的提交只是一个补丁集，而不是提交的更改。有没有人建议通过消除上面的一些痛点来改善这个工作流程？