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