多个git存储库的最佳实践

Question

我有大约20个不同的存储库。许多库是独立的，并作为库编译，但其他一些库之间存在依赖关系。依赖性解析和分支是复杂的。

假设我有一个只聚合所有其他存储库的超级项目。它只用于运行测试--这里没有真正的开发。

/superproject  [master, HEAD]
    /a         [master, HEAD]
    /b         [master, HEAD]
    /c         [master, HEAD]
    /...

现在，要为每个特性(a)，特别是需要特定版本的项目来编译或运行(b v2.0和c 3.0)的特性或修复(b v2.0和c 3.0)，必须创建一个新分支：

/superproject  [branch-a, HEAD]  <-- branch for 'a' project
    /a         [master]  <-- new commits here
    /b         [v2.0]
    /c         [v3.0]

对于b，可能需要其他一些东西，比如a v0.9和c v3.1

/superproject  [branch-b, HEAD]  <-- branch for 'b' project
    /a         [v0.9]   <-- older version than 'a'
    /b         [master] <-- new commits go here
    /c         [v3.1]   <-- newer version than 'a'

当实现涉及特性分支、修复分支、发布分支等的通用git工作流时，这变得更加复杂和复杂。有人建议我使用git-submodules、git-subtree、谷歌的git-repo、git-slave等。

对于如此复杂的项目，我如何管理连续集成？

编辑

真正的问题是如何运行测试而不必模拟所有其他依赖的项目？特别是当所有项目可能使用不同的版本时。在git子模块提交后触发Jenkins测试

Answer 1

若要并行处理多个分支，请尽可能使用并行克隆。cd比每次你想切换的时候都要容易得多，比结账、清理和检查陈旧的垃圾和重新缓存容易得多。

就记录测试环境而言，在每个细节中，您所描述的都是子模块所做的事情。对于这么简单的事情，我将建议您自己设置，而不使用子模块命令，并告诉它您的设置，一旦您感到舒适，并在您的子模块上的首要项目-问题列表是键击计数。

从问题中的设置开始，下面介绍如何在子项目中记录干净的构建：

cd $superproject
git init .
git add a b c etc
git commit -m "recording test state for $thistest"

就这样。您已经提交了一个提交id的列表，即当前签出的每个repos中的id。实际内容是在这些repos中，而不是在这个，但这是文件和子模块之间的全部区别。.gitmodules文件有用于帮助克隆人的随机注释，主要是一个建议的repo，它应该包含必要的提交，以及用于命令默认值的随机注释，但是它所做的事情是简单而明显的。

想要签出路径foo上的正确提交

(commit=`git rev-parse :foo`; cd foo; git checkout $commit)

rev-解析从索引中获取foo的内容id，cd和checkout就会这样做。

下面是如何找到您的所有子模块，以及要重新创建分阶段的aka索引环境应该检查的内容：

git ls-files -s | grep ^16

检查当前子模块的索引列表以及实际检查的内容：

echo $(git rev-parse :$submodule; (cd $submodule; git rev-parse HEAD))

然后就到了。检查所有子模块中的右提交？

git ls-files -s | grep ^16 | while read mode commit stage path; do
        (cd "$path"; git checkout $commit)
done

有时，您携带的是要应用于每次结帐的本地修补程序：

git ls-files -s | grep ^16 | while read mode commit stage path; do
        (cd $path; git rebase $commit)
done

以此类推。这些都有git submodule命令，但它们并没有执行您在上面没有看到的任何操作。对其他人来说，你也可以把他们做的每一件事都翻译成类似于上面的那些。

子模块没有什么神秘之处。

持续集成通常是与许多工具中的任何一种一起完成的，我将把它留给其他人来解决。

Answer 2

作为作者，git slave可以在这种情况下工作。如何使用它将取决于您是否控制了repos、a、b和c；我的意思是，您可以使分支策略在它们之间进行同步，从而使v2分支对每个人都有相同的意义。如果是这样的话，我强烈建议git slave，因为您基本上可以将它作为一个大型项目来处理。

如果您不能强制执行公共分支和标记策略，那么您将强制执行一种策略，这将更加接近于jthill建议使用git submodules的轻量级工作流版本。具体来说，您可以拥有自己的回购跟踪a b和c，并在每个分支中创建一个branch a分支，这将对应于每个从回购的正确分支。与git submodules一样，您必须手动更新每个回购(在本例中为合并)。然而，您不需要做母亲-可能-我的步骤作出承诺的超级工程。使用这种技术并不是让从项目在进行自己的开发时共享相同的分支名称，但它是可以工作的。

正如jthill所说，连续集成几乎与如何争论项目的问题是正交的。