これらのプロジェクトがどれほど密接に関連しているかによって異なります。次の質問を自問してください。
それらをすべて1つにまとめると、上からのいくつかのことが簡単になります。リポジトリごとに個別に行うのではなく、1つのリポジトリでブランチ/タグ/スタッシュ/コミットするだけで済みます。
ただし、たとえばプロジェクトごとに個別のリリースサイクルが必要な場合は、各プロジェクトを独立したリポジトリに配置する必要があります。
後でいつでもリポジトリを分割したり、履歴を失うことなく複数のリポジトリを1つに結合したりできることに注意してください。
結合は分割よりも少し難しいので、最初に1つのリポジトリに移動して、それがどのように行われるかを確認します。
プロジェクトごとに1つのリポジトリを使用します。
いくつかの理由：
いくつかのコミットの後で何かを台無しにしたことに気付いたとき、それがたった1つのプロジェクトである場合、修正するのははるかに簡単です。考えてみてください。他の2つのプロジェクトにコミットしたので、3番目のプロジェクトで行ったコミットを修正する必要があります。
フェディールが言ったように、あなたの履歴とログはずっときれいです。そのプロジェクトのコミットのみが表示されます。
それは私が持っている開発ワークフローでうまく機能します。私は本番用のマスターブランチを持っており、開発用のブランチを開発し、機能を実装するためのブランチを作成しています（詳細については、http：//blog.avirtualhome.com/development-workflow-using-git/を参照してください）。 ）。
チームで作業し、gitリポジトリを「共有」する場合、チームメンバーは他のすべてのプロジェクトも本当に必要ですか？
ほんの少しの考えですが、要約すると、次のようになります。自分に合った方法を実行してください。
私は複数のプロジェクト（Eclipseプロジェクト）を持っており、実際の日々の開発の観点から何が最も効果的かを見つけるためにさまざまなことを試みました。これが私が見つけたものであり、結果を追跡して客観的に分析すれば、ほとんどの人が同じことを見つけるだろうと思います。
つまり、次のルールを適用すると、最良の結果が得られます。
次のガイドラインは、同じリポジトリに配置するプロジェクトを決定するためのこのプロセスをより詳細に説明しています。
プロジェクトが他のプロジェクトと密接に関連していない場合（たとえば、他のプロジェクトを開かなくてもプロジェクトを開くことができ、他のプロジェクトが開いたときに開いているプロジェクトに依存しない場合）、必ず独自のリポジトリに配置する必要があります上記の回答で説明されている理由によります。
プロジェクトが他のプロジェクトに依存している場合、または他のプロジェクトがプロジェクトに依存している場合は、それらが互いにどの程度接続されているか、それらをどれだけうまくパッケージ化できるか、およびどれだけ簡単に互いに分離できるかによって決まります。
A）たとえば、メインプロジェクトのクラスをテストするためのjunitテストクラスを含むテストプロジェクトは、2つのプロジェクトが互いに非常に接続されており、簡単にパッケージ化でき、簡単に分離できない場合です。これらのプロジェクトは、以下のパートCで説明する理由により、同じリポジトリに配置する必要があります。
B）あるプロジェクトが、ある種の共有リソースを提供するために別のプロジェクトに依存している場合、それらを一緒に管理できるかどうか、およびそれらを互いに分離できるかどうかにかかっています。たとえば、共有リソースを持つプロジェクトが多くのプロジェクトに依存している場合、他の無関係なプロジェクトは共有ソースコードプロジェクトへの変更の影響を受けるため、それを独自のリポジトリに配置する必要があります。このような場合、共有リソースプロジェクトは、依存プロジェクトに直接接続するのではなく、依存プロジェクトから切り離す必要があります。（たとえば、バージョン管理されたアーカイブファイル[「projectName」.1.0.1.0のような名前のJarファイルを作成することをお勧めします。
C）複数のプロジェクトが接続されていて、簡単に一緒に管理できるが、互いに簡単に切り離すことができない場合は、それらが互いにどれだけ緊密に接続されているかによって異なります。
I）プロジェクトが1つのリポジトリに配置されている場合、コミットが行われるたびにプロジェクトはリポジトリ内で相互に同期されます。これは、プロジェクトが緊密に接続されている場合、実際の節約になります。ただし、これにより、上記の回答に記載されている問題も発生します。
II）プロジェクトが別々のリポジトリに配置されている場合は、コミットの同期を維持するように注意し、プロジェクト全体で同じ同期ポイントに属するコミットを示す何らかのメカニズムを含める必要があります（おそらく、プロジェクト全体でコミットのグループが実行されるときに、各プロジェクトのコミットのコメントに同じ同期ポイント番号を含めるようなものです。）
III）したがって、このような場合は、ほとんどの場合、これらのプロジェクトを1つのリポジトリにまとめて、コミットの同期にかかる人的労力のオーバーヘッドを減らし、コミットを取り消す必要がある場合の人的エラーを回避することをお勧めします。それらを別々のリポジトリに配置する方がよい場合は、プロジェクトの1つだけが定期的に変更され、他の接続されたプロジェクトはめったに変更されない場合のみです。
この質問は、私がここで答えた質問に関連していると思います。基本的に、Gitはその性質上、プロジェクト/リポジトリに関しては非常に細かい粒度の構造をサポートします。私は、プロジェクトごとに1つのリポジトリがほとんどの場合、ベストプラクティスであることを読み、教えられてきました。他の人が説明しているように、プロジェクトを分離しておくことでほとんど何も失うことはなく、多くを得ることができます。
おそらく、複数のgitリポジトリを作成する場合は、作業のパフォーマンスが向上します。
ブランチを作成する場合、プロジェクトのファイルのみがブランチされ、すべてのプロジェクトがブランチされるわけではありません。小さなプロジェクトでは、分析とコミットがより高速になります。操作にかかる時間は短くなります。
ログもより明確になります。複数のgitリポジトリがある場合は、よりきめ細かい構成を作成できます。