git - 使用git子树 merge ，同时也 merge 所有 merge 子树的所有分支

Question

我想使用提供 git 集成的流行的开源问题跟踪器 (Redmine)。不幸的是，跟踪器中的每个项目只能与一个 git repo 相关联。在跟踪器中创建多个项目不是我理想的设置。

考虑到这一点，我尝试使用 git 子树 merge (解释为 here 和 here )。我创建了一个“伞形”存储库，它已 merge 到我正在使用的众多其他存储库中。

不幸的是，给出的例子只 pull 入每个子树的主分支。由于我在每个子树的多个分支中进行开发，因此我需要学习如何让这个伞形仓库反射(reflect)每个子树的每个分支。

这可能吗？

额外学分:如果 2 个子树各有一个同名分支怎么办？

Answer 1

对于我们这些不熟悉 Redmine 的人，请扩展您的描述以包括以下问题的答案:跟踪器需要什么样的存储库访问权限？它需要自己提交吗？或者，它是否只需要某些类型的读取访问权限(也许是为了验证提交哈希并扫描提交日志中的关键字)？

如果您的跟踪器只需要读取访问权限，您可能根本不需要任何子树 merge 。在单个存储库中有多个初始提交(允许多个独立的历史记录)是完全可以接受的。 Git 项目本身为一些不共享(提交)历史的“额外”(man、html、todo)执行此操作，但与源代码的主要分支集(maint、master、next、pu)一起发布。为了您的目的，为每个子存储库设置一个远程并将它们的分支提示提取到您的聚合存储库中可能就足够了。也许自动的“远程跟踪分支”就足够了，或者您可能需要采取额外的步骤来基于远程跟踪分支创建(和更新)本地分支。

您描述的子树 merge 方案在源存储库中的分支不相关或仅半相关的一般情况下可能没有意义。但是，如果所有源存储库共享一组分支，其中每个分支的给定用途在所有存储库中都相同，那么您可能可以有意义地将它们 merge 为一种 super 存储库。

但有趣的问题不是“如果两个存储库具有相同名称的分支怎么办？”，而是“您如何处理存储库缺少共享的‘全局’集合中的分支的情况？”。

如果所有子存储库都具有相同的一组分支，您只需执行对 master 所做的操作，但每个分支一次。当存储库中缺少特定分支时，就会出现问题。您可以替换它的主人，但这可能并不总是正确的答案。这取决于您首先将存储库聚合在一起的原因以及您希望在 super 存储库中该分支的子树中“看到”的内容。

如果子存储库不是紧密相关的，那么我真的很怀疑这种子树方法的合理性。这种用于不相关存储库的方法感觉像是“违背常规”。这可能仍然是可能的，但我怀疑是否有任何工具可以提供帮助，您需要花一些时间来规划极端情况。

如果您最终坚持使用子树 merge ，您可能会查看第三方 git subtree 命令。它可能有助于保持您的无数存储库同步。

收集分支，不 merge

如果 Redmine 指定 --mirror clone，这意味着它需要本地分支，并且可能无法直接读取“远程跟踪分支”，因此您可能需要创建和更新一些本地分支。

从“远程跟踪分支”更新的本地分支

最初设定

mkdir $COLLECTION_REPO && cd $COLLECTION_REPO &&
git init
git remote add alpha <url/path-to-alpha-repo>
git remote add bravo <url/path-to-bravo-repo>
git remote add charlie <url/path-to-charlie-repo>
for r in $(git remote); do
    git config --add remote.$r.fetch \
      "$(git config remote.$r.fetch | sed -e 's.heads.tags.;s.remotes.tags/all.')"
    git config remote.$r.tagopt --no-tags
done

定期更新

git remote update
git for-each-ref --shell --format \
  'git branch --force --track -l all/%(refname:short) %(refname:short)' refs/remotes \
  | sh

直接接收获取的分支提示的本地分支

最初设定

mkdir $COLLECTION_REPO && cd $COLLECTION_REPO &&
git init
git remote add alpha <url/path-to-alpha-repo>
git remote add bravo <url/path-to-bravo-repo>
git remote add charlie <url/path-to-charlie-repo>
for r in $(git remote); do
    git config remote.$r.fetch \
      "$(git config remote.$r.fetch | sed -e 's.remotes.heads/all.')"
    git config --add remote.$r.fetch \
      "$(git config remote.$r.fetch | sed -e 's.heads.tags.g')"
    git config remote.$r.tagopt --no-tags
done

定期更新

git remote update

这两种方法最终都会收集 refs/heads/all/<remote-name>/<branch-name-on-remote> 下的分支。 ，但第一个在 refs/remotes/<remote-name>/<branch-name-on-remote> 下也有一组重复的引用文​​献.第一个使用普通的 fetch refspec 并使用 git branch将“远程跟踪分支”( refs/remotes/… )复制到正常的本地分支( refs/heads/all/… )中。第二个使用自定义 refspec 将获取的 ref 直接存储到目标 ref 层次结构中。

由于更新被盲目地提取到这个组合存储库中的方式，任何人都不应该尝试直接使用它:没有直接在其分支上进行提交，也没有来自外部的推送。如果有人要在本地进行提交或推送到其中一个分支，那么在下一次更新完成时，这些提交将被清除。

如果 Redmine 可以处理裸存储库，我会建议使用一个。使用 git init --bare以及以 .git 结尾的 repo 名称。还有 git config core.logAllRefUpdates true可能是个好主意(因为这在裸存储库中默认为 false)。

除了 all/命名空间中的前缀，此方法与完整 --mirror 之间的另一个区别克隆是外部引用 refs/heads和 refs/tags不会被收集。大多数其他常见引用被认为是存储库的“本地”(这就是为什么它们不会被普通克隆复制)。其他一些引用是“远程跟踪分支”( refs/remotes )，一些“二等分”记录保存( refs/bisect )，git filter-branch “原始”引用备份(refs/original)等。对于Redmine来说，这些其他事情可能都不重要。如果是，它们也可以包含在额外的引用规范中。

创建额外的初始提交

要使用新的初始提交安排分支，请参阅 GitTips page下 How to create a new branch that has no ancestor .其中两个配方涉及另一个存储库，您可以在完成通常的 init/add/commit 步骤(正是上述配方以自动方式执行的操作)后从中推送或获取分支。