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

Question

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

考虑到这一点，我尝试使用 git 子树合并（解释此处和此处 ）。我创建了一个“伞”存储库，它已合并到我正在使用的众多其他存储库中。

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

这可能吗？

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

Answer 1

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

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

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

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

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

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

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

---

收集分支，而不合并

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

Local Branches Updated From ‘Remote Tracking Branches’

• 初始设置

  mkdir $COLLECTION_REPO && cd $COLLECTION_REPO &&
  git初始化
  git Remote add alpha ;
  git Remote add bravo ;
  git Remote add charlie ;
  for r in $(git remote);做
      git config --添加远程。$r.fetch \
        “$(git config remote.$r.fetch | sed -e 's.heads.tags.;s.remotes.tags/all.')”
      git config remote.$r.tagopt --no-tags
  完毕
  

• 定期更新

  git远程更新
  git for-each-ref --shell --format \
    'gitbranch --force --track -l all/%(refname:short) %(refname:short)' refs/remotes \
    |嘘
  

Local Branches That Directly Receive Fetched Branch Tips

• 初始设置

  mkdir $COLLECTION_REPO && cd $COLLECTION_REPO &&
  git初始化
  git Remote add alpha ;
  git Remote add bravo ;
  git Remote add charlie ;
  for r in $(git remote);做
      git config 远程。$r.fetch \
        “$(git config remote.$r.fetch | sed -e 's.remotes.heads/all。')”
      git config --添加远程。$r.fetch \
        “$(git config remote.$r.fetch | sed -e 's.heads.tags.g')”
      git config remote.$r.tagopt --no-tags
  完毕
  

• 定期更新

  git远程更新
  

这两种方法最终都会收集 refs/heads/all// 下的分支，但是首先在 refs/remotes// 下还有一组重复的引用。第一个使用普通的 fetch refspec 并使用 gitbranch 将“远程跟踪分支”（refs/remotes/…）复制到普通的本地分支（refs） /heads/all/...）。第二个使用自定义 refspec 将获取的引用直接存储到目标引用层次结构中。

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

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

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

创建额外的初始提交

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