Question

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

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

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

现在，为每个（a）开发特定功能或修复程序，尤其是那些需要编译或运行特定版本项目（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，google＆＃39; s git-repo，git-slave等

如何为这样一个复杂的项目管理持续集成？

修改

真正的问题是如何在不必模拟所有其他依赖项目的情况下运行测试？特别是当所有项目可能使用不同版本时。 Trigger Jenkins tests after commits in git submodules

Answer 1

要并行处理多个分支，请尽可能使用并行克隆。每次要切换时，cd比结帐更简单，清理并检查陈旧破坏和重新创建缓存。

就记录测试环境而言，您所描述的内容正是子模块在每个细节中的作用。对于这个简单的事情，我建议你不要使用子模块命令就自己设置，并在你熟悉后告诉它你的设置，子模块问题列表中的顶部项目是按键计数

从你问题中的设置开始，这里是你如何设置自己在子项目中记录干净的构建：

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

那就是它。您已经提交了一份提交ID列表，即每个回购中当前已检出的提交的ID。实际内容是在那些存储库中，而不是这个存储库，但就git而言，这是文件和子模块之间的全部区别。 .gitmodules文件有随机笔记来帮助克隆者，主要是建议的包含必要提交的回购，以及命令默认的随机注释，但它所做的事情很简单明了。

想要查看路径foo上的正确提交吗？

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

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

以下是您如何查找所有子模块以及应该检查哪些子模块以重新创建分阶段的索引环境：

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命令，但是他们没有做任何你不能做的事情。对于所有其他人来说，你可以将他们所做的一切都翻译成像上面那样的近线者。

子模块没什么神秘之处。

持续整合通常使用any of a whole lot of tools完成，我会留给其他人解决。

Answer 2

作为作者，git slave可以在这种情况下工作。如何使用它取决于您是否可以控制回购a b和c;我的意思是你可以使分支策略在它们之间同步，这样v2分支对每个人来说意味着同样的事情。如果这是真的，我强烈要求git slave，因为你基本上可以将它视为一个大型项目。

如果你不能强制执行一个通用的分支和标记策略，那么你会强加一个，这会更多地转向jthill用git submodules建议的工作流的轻量级版本。具体来说，您可以拥有自己的仓库跟踪a b和c并在每个仓库中创建一个branch a分支，这对应于每个从属仓库的正确分支是。与git submodules一样，您必须手动使每个仓库更新（在这种情况下合并）。但是，您不需要在超级项目中执行母亲可能的步骤。使用这种技术并不是让奴隶项目在进行自己的开发时共享相同分支名称的灌篮使用案例，但它会起作用。

正如jthill所说，持续整合与如何纠缠项目的问题非常相似。

多个git存储库的最佳实践

2 个答案: