【发布时间】：2013-07-29 20:34:53
【问题描述】：
我正在处理许多需要合并在一起的不同 Git 存储库。工作流程如下所示：
git remote add fork1 ...
git remote add fork2 ...
git fetch fork1
git fetch fork2
git merge fork1/master fork2/master
这一切都很好，但我希望能够使用标签提取每个远程的特定提交：
git merge fork1/v1.0.0 fork2/v2.1.0
永远不应该有任何合并冲突，因为每个 repo 将其更改限制在一个子文件夹中，但即使有，章鱼合并也会导致整个事务自动失败。
问题出在标签引用上。如this blogpost（不是我的）中所述，所有标签都莫名其妙地转储到全局命名空间中。没有办法说fork1/v1.0.0 - 它只是v1.0.0，如果多个存储库具有相同的标签，它们会相互挤压。
在this answer 之后，我一直在研究使用 refspecs 来解决这个问题。到目前为止，我想出了以下几点：
git fetch fork1 refs/tags/*:refs/tags/fork1/*
这具有使 fork1 的 v1.0.0 标记作为 fork1/v1.0.0 到达的预期效果。不幸的是，它也以未命名空间的v1.0.0 的形式出现； git fetch 在标签映射部分打印出两倍的行数，git merge v1.0.0 仍然与拉出的标签合并。我在任何地方都找不到关于 refspecs 的好的文档（Git's documentation on the topic 非常没用）。
如何防止来自多个存储库的标签相互冲突？
如果我只是愚蠢地处理这个问题，我也愿意接受其他工作流程建议。我有一个包含共享组件和结构的核心存储库，以及许多模块存储库，它们是核心的完整克隆，只添加了它们的代码。我目前的计划是让每个模块都有一个指向核心的远程指针（以保持共享部分的最新状态）以及它所依赖的每个其他模块。共享位会合并，因为它们相同，模块位会合并，因为它们是独立的。我应该在这里遵循另一种模式吗？ （我避免使用子模块，因为（a）我从来没有听说过它们的好消息，并且（b）共享部分在项目目录结构方面是顶层，这使得 repo 结构非常尴尬。）
【问题讨论】：
-
这是需要自动化或可重复的吗？还是这是一次性事件？
-
可重复和自动化。这些模块将由不同的团队维护，并且应该能够在将来的任何时间更改为依赖彼此和核心的不同版本。我还希望能够从我们的 CI 服务器的配置中轻松派生相关命令。
标签： git tags multiple-repositories refspec