如何实现拉入不是镜像的裸存储库的效果？答案

【问题标题】：How can I achieve the effect of pulling into a bare repository which isn't a mirror?如何实现拉入不是镜像的裸存储库的效果？
【发布时间】：2013-10-23 16:36:46
【问题描述】：

我正在尝试建立一个存储库系统，允许项目共享一个“框架”远程，以便可以将框架的错误修复拉入项目中。

我的方法是在//NAS/projects/base 建立一个裸存储库，将其克隆到//NAS/projects/projectX 的裸存储库，并将projectX 的远程从origin 重命名为framework 以避免混淆。目的是每个开发人员都可以克隆//NAS/projects/projectX 并将其更改推送回该存储库，框架维护者可以克隆//NAS/projects/base 并将其更改推送回该存储库。然后projectX 可以从基础拉取 - 在这里我的方法失败了，因为我无法拉入裸存储库。

existing questions 的设置看起来表面上相似，但经过检查似乎只解决了第二个裸存储库是第一个存储库的镜像的情况。这不是这里的情况：我希望能够创建一个projectY，它也使用框架并获取其更改，但没有任何特定于projectX 或projectY 的代码以base 结尾。

git 是如何支持这种结构的？是否有人需要将base 作为远程添加到他们的本地存储库，从中提取，然后推送到projectX？我可以从base 获取到projectX：然后我可以执行一些命令将其主控重新设置为base 主控的HEAD？还是我以完全错误的方式解决这个问题？

【问题讨论】：

框架是项目使用的库，还是更多的被编辑和/或构建的核心组件？如果它是一个库，我会在它自己的存储库中跟踪它，并使其成为使用它的项目中的子模块。
@cjc343，第二个。它在结构上不适合子模块方法。

标签： git git-bare

【解决方案1】：

简短的回答：您需要让项目所有者从基础获取到他们的本地（非裸）存储库，并将错误修复/更新从基础合并到他们的 projectx/master 分支（或将他们的 master 重新设置到基础上）。从那里他们可以将更新的 projectx 状态推送回服务器以供其他人使用。（见git merging branches in a bare repository）

如果我理解正确的话，base 就像 OO 层次结构中的基类，而项目就像派生类，自动继承对 base 的更改，但实现一些不同的东西，对吗？否则，如果它更像是“具有框架功能的基础库”类型的情况，那么要走的路将是一个单独的项目，由其他项目引用（例如通过子模块），正如您问题下的评论所暗示的那样。

您似乎想要的是一种从基础到项目的自动错误修复集成，所有这些都在服务器上的裸存储库中。这将不起作用，因为 git 显示合并/rebase 的错误消息（“此操作必须在工作树中运行”），原因很简单：即使它可以在 repo 中合并，git 也不能保证在那里在合并期间不会发生冲突（也许有人已经在同一位置应用了不同的错误修复），并且要解决合并冲突，您需要手动编辑受影响的文件，为此您需要签出工作复制。即使没有冲突，git 也必须创建一个“临时”工作副本来应用更改，然后再次提交。这不是 git 的工作方式：repo 只是项目状态在某个时间点的（压缩）快照的集合。您只需向其中添加新快照，您不会修改其中已有的快照。（提取到裸 projectx 远程（而不是拉取）有效，因为这只会将完整的 blob 和 refs 复制到存储库中以使提取的远程分支可用，但不会修改现有分支。）

如果您想要一个主要是自动化的解决方案，您可以使用一个 shell 脚本，该脚本会定期从基础中获取，将更新合并到项目中，并将更新的项目主节点推送到服务器，如果在此过程中没有发生合并冲突。不过，我建议不要这样做，因为如果出现合并未捕获的“功能”冲突，您将遇到问题，在这种情况下，只要项目不兼容，您就必须停止自动脚本基地的新变化。根据发生这种情况的可能性，谨慎行事（在不稳定的更新分支或其他地方）。

【讨论】：