0

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

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

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

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

4

1 回答 1

1

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

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

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

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

于 2013-10-28T20:03:56.493 回答