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