使用git子树合并，同时也在所有合并子树的所有分支中进行合并

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

考虑到这一点，我尝试使用 git 子树合并（解释为here http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html, and here http://blog.nuclearsquid.com/writings/subtree-merging-and-you）。我创建了一个“伞”存储库，它已合并到我正在使用的众多其他存储库中。

不幸的是，给出的示例仅拉入每个子树的主分支。由于我在每个子树的多个分支中进行开发，因此我需要学习如何让这个伞式存储库反映每个子树的每个分支。

这可能吗？

额外加分：如果 2 个子树各有一个同名的分支怎么办？

对于我们这些不熟悉 Redmine 的人，请扩展您的描述以包括以下问题的答案： 跟踪器需要对存储库进行何种访问？它需要自己做出承诺吗？或者，它是否只需要某些类型的读取访问（可能是为了验证提交哈希值并扫描提交日志中的关键字）？

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

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

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

如果所有子存储库都有相同的分支集，您只需执行与master，但每个分支一次。当存储库中缺少特定分支时就会出现问题。你可以替换它master，但这可能并不总是正确的答案。这取决于您首先将存储库聚合在一起的原因以及您期望在超级存储库中该分支的子树中“看到”什么。

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

如果您最终坚持使用子树合并，您可以查看第三方git subtree http://github.com/apenwarr/git-subtree/blob/master/git-subtree.txt命令。它可能有助于保持无数存储库的同步。

收集分支，不合并

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

• 初始设置

  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 将获取的引用直接存储到目标引用层次结构中。

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

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

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

创建额外的初始提交

要安排具有新初始提交的分支，请参阅Git 提示页面 http://git.wiki.kernel.org/index.php/GitTips under 如何创建一个没有祖先的新分支 http://git.wiki.kernel.org/index.php/GitTips#How_to_create_a_new_branch_that_has_no_ancestor。其中两个配方涉及另一个存储库，在完成通常的初始化/添加/提交步骤后，您可以从该存储库推送或获取分支（正是上述配方以自动化方式执行的操作）。