相关疑难解决方法(0)

高度耦合的git子模块

我有一个项目需要分成两个存储库:一组通用模型,以及基于这些模型的模拟,以及其他代码.最终可能会有多个模拟使用同一组模型,因此将它们放在一个单独的存储库中是一个明确的要求.显而易见的解决方案是将通用模型作为模拟的子模块.

不幸的是,这两个库的工作将非常高度耦合.人们会经常在他们的常见模型中添加一些东西,然后立即在模拟中使用它.我想这会在模拟回购的整合过程中引起很多麻烦.为了在模拟中合并来自许多开发人员的更改,集成商将不得不在通用模型子模块中进行并行合并.另一方面,它也使得使用子模块变得至关重要 - 模拟真的需要知道它应该使用哪个版本的常见模型.

该项目由相当多的人开展.大多数开发人员只对git有一个非常粗略的了解:他们添加文件,提交和从源头拉取很多东西,并希望有一个开发和稳定的分支.积分器自然学到了很多东西,但任何涉及子模块的东西对他来说肯定都是新的.额外的奖励:我即将休假一个月,所以我将无法扑灭任何火灾.结果是,有很多动机使工作流程变得非常难以搞砸,并最大限度地减少与以前工作流程的差异.

所以,我的问题是:我是否会后悔建议我们使用子模块?(有更好的想法吗?)我可以期待人们犯下什么样的错误,所以我可以提前警告他们?是否有任何好的工作流程策略要记住?

编辑:我刚遇到git slave,在这种情况下也许值得一看.还不能对其网站上的能力/限制进行良好的评估.

git git-submodules

16
推荐指数
2
解决办法
2300
查看次数

标签 统计

git ×1

git-submodules ×1