它可能不会直接回答您的答案,但我认为这种特殊情况可以通过 Git 的submodules等功能来解决。
在这种情况下,无论如何,您需要在某个地方托管两个不同的存储库。但是在子模块的帮助下,你可以告诉 Git 一个 repo 的文件应该位于另一个 repo的目录树中。不会造成你描述的混乱!
例如,假设您将项目托管为github.com/user/Client
和github.com/user/Server
repos。转到Client
存储库的文件夹并执行以下操作:
git submodule add git@github.com:user/Server.git src/server
这会将具有给定地址的 repo 克隆到您指定的文件夹中(src/server
在本例中)。
之后,您必须提交更改。虽然添加了很多文件,但commit diff不会有很多变化:特殊文件中只有一个简短的记录,说这样的存储库现在是一个子模块。也就是说,Server
实际上并没有存储在Client
repo 中的文件,只存储了对它们的引用。这就是 git 子模块的强大之处。
请注意,在那之后,当您在Client
其他地方克隆您的 repo 时,默认情况下不会获取其子模块。您必须使用git submodule update --init
来初始化子模块。
另请注意,Server
对子模块的引用指向它的特定版本。对 repo进行一些更改后,Server
您可能想要转到Client
repo,导航到子模块的目录(src/server
在本示例中)并在repo中进行简单的git pull
更改并提交更改。Client
同样,不会有巨大的差异,只会提交对子模块的新引用。
作为带有子模块的 repo 的示例,您可以查看我的 Vim 设置目录的 repo:它的bundle文件夹中有许多插件,它们都是 git 子模块。GitHub 很好地展示了它们,如果它是 GitHub 托管的,则可以轻松地一键导航到子模块 repo。
PS 如果这一切与您想要的没有任何共同之处,而您只是想将一个文件夹Server
添加到 repo Client
,您可以复制Server
到客户端并通过删除目录中的所有 Git 痕迹Server
(如果有的话)删除.git
它。现在您只需拥有一个 repo,提交所有这些更改并继续。这样做的缺点是完全丢失了Server
回购的历史——在项目的初始阶段这并不是一个很大的痛苦。