Git子模块/子树陷阱

时间:2018-01-14 18:32:51

标签: git

我有一个存储库A,我需要为其他团队B提供对特定文件夹的访问权。

方案如下。当团队A在整个A存储库上工作时,保持正常工作,当他们只推送A \ B文件夹中所做的更改时,必须进入存储库B.

当B团队修改B存储库中的代码时,A存储库中的开发人员应该相应地获取它。

基本上它是一对一的对应关系。最新的A代码和最新的B代码应始终保持同步。

团队经常修改代码。 B团队很少修改代码。

B团队的开发过程必须尽可能顺利。理想情况下,A队也应该顺利。

我已经考虑了子模块和子树,但很多文章建议摆脱子模块并仅使用子树。

我已经开始使用子树方法,首先,为了保持代码同步,我为A开发人员编写了两个脚本来从B存储库中提取代码。

git subtree pull B git subtree push B

然而推送方法效果不好,因为B团队很少工作,所以没有频繁的更改,并且git子树不够智能,记住上次同步提交并不断重复检查它们(该过程在{期间完成) {1}}在git subtree split)内调用

我尝试了很多方法并最终编写了脚本,每次推送存储库时都会在B存储库中进行人工虚假提交。这种方法有效但从那时起提交日志看起来很脏。

另一个问题是,将所有这些脚本魔法与Pull Request例程集成起来非常困难,因此我必须编写脚本来接受Pull Requests,它会为B存储库调用我的附加逻辑。

对我而言,所有这些看起来像是在做一些非常错误的事情。

我开始调查子模块,发现他们对A开发人员和Pull请求也非常不友好。

我正在寻求社区输出如何在没有这样的开销的情况下解决这么简单的问题

1 个答案:

答案 0 :(得分:0)

在这种情况下,我肯定会选择子模块。这正是它的目的所在。在项目之间共享代码(repos)。 但是,正如您所说,使用和理解并不容易。 在开始使用之前先阅读它。 一旦你对它的工作方式感到满意,它就会变得非常简单。 祝你好运!