我正在尝试建立一个存储库系统，允许项目共享一个“框架”远程，以便框架的错误修正可以被拉入项目。
我的方法是在//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？或者我是以完全错误的方式解决这个问题？
答案 0 :(得分：1)
简短回答：您需要让项目所有者从基地获取到他们的本地（非裸）存储库，并将错误修正/更新从base合并到他们的projectx / master分支（或将他们的master重新绑定到base）。从那里，他们可以将更新的projectx状态推送回服务器，供其他人使用。 （见git merging branches in a bare repository）
如果我理解正确，base就像是OO层次结构中的基类，项目就像派生类一样，自动继承对base的更改，但实现一些不同的东西，对吗？否则，如果它更像是一个“具有框架功能的基础库”类型的情况，那么前进的方式将是一个单独的项目，由其他项目引用（例如通过子模块），正如您的问题所暗示的那样。
您似乎想要的是从基础到项目的一种自动错误修复集成，所有这些都在服务器上的裸存储库中。这不起作用，因为git指示merge / rebase的错误消息（“此操作必须在工作树中运行”），原因很简单：即使它可以在repo中合并，git也不能保证在合并期间不会发生冲突（可能有人已经在同一位置应用了不同的错误修复），并且要解决合并冲突，您需要手动编辑受影响的文件，为此您需要检查工作复制。即使没有冲突，git也必须创建一个“临时”工作副本来应用更改，然后再次提交。这不是git的工作方式：repo只是一个时刻项目状态的（压缩）快照的集合。您只需向其添加新快照，不要修改已经存在的快照。 （获取裸露的projectx远程（而不是拉动）是有效的，因为这只会将完整的blob和refs复制到存储库中，以使获取的远程分支可用，但不会修改现有的远程分支。）
如果您想要一个主要是自动的解决方案，您可以使用定期从base获取的shell脚本，将更新合并到项目中，并在此过程中没有发生合并冲突时将更新的项目主机推送到服务器。但是，我建议不要这样做，因为如果出现一个未被合并捕获的“功能”冲突，你会遇到问题，在这种情况下，只要项目不兼容，你就必须停止自动脚本。基数的新变化。根据发生这种情况的可能性，请谨慎行事（在unstable_updates分支或其他内容中）。