おそらくあなたの答えには直接答えませんが、この特定の状況はsubmodulesなどの Git の機能で支配できると思います。
この場合、とにかく、2 つの異なるリポジトリをどこかにホストする必要があります。しかし、サブモジュールの助けを借りて、あるレポのファイルを別のレポのディレクトリ ツリー内に配置する必要があることを Git に伝えることができます。あなたが説明した混乱を引き起こすことなく！
たとえば、プロジェクトがリポジトリとしてホストされているgithub.com/user/Clientとします。リポジトリgithub.com/user/Serverのフォルダーに移動し、次の操作を行います。Client
git submodule add git@github.com:user/Server.git src/server
これにより、指定したアドレスのレポが指定したフォルダー (src/serverこの例では) に複製されます。
その後、変更をコミットする必要があります。多くのファイルが追加されましたが、commit diff には多くの変更はありません: そのようなリポジトリが現在サブモジュールであることを示す短い記録が特別なファイルにあるだけです。つまり、ファイルはServer実際にはClientレポに保存されず、それらへの参照のみが保存されます。これが git サブモジュールの力です。
Clientその後、レポを別の場所に複製すると、そのサブモジュールはデフォルトで取得されないことに注意してください。git submodule update --initサブモジュールを初期化するために使用する必要があります。
Serverサブモジュールへの参照は、その特定のリビジョンを指していることにも注意してください。Serverリポジトリにいくつかの変更を加えた後、Clientリポジトリに移動し、サブモジュールのディレクトリ (src/serverこの例では) に移動し、リポジトリで簡単なgit pull変更をコミットしますClient。繰り返しになりますが、巨大な差分はなく、サブモジュールへの新しい参照のみがコミットされます。
サブモジュールを含むリポジトリの例として、Vim 設定ディレクトリのリポジトリを確認できます。バンドルフォルダ内に多くのプラグインがあり、それらはすべて git サブモジュールです。GitHub はそれらを非常によく示しており、GitHub でホストされている場合は、サブモジュール リポジトリへのワンクリック ナビゲーションを簡単に実行できます。
PSこれがあなたが望むものと何の共通点もなく、単にフォルダServerを repo に追加したい場合は、クライアントClientにコピーしてディレクトリからGitのすべての痕跡を削除するだけです（ある場合）その中を削除します。これで、レポが 1 つだけになり、この多くの変更をすべてコミットして続行できます。これの欠点は、レポの履歴が完全に失われることです。プロジェクトの初期段階では大きな苦痛ではありません。ServerServer.gitServer