私はGitへの移行を開始する典型的なEclipse/Subversionユーザーです。私はgitの基本的な概念を研究し、物事を単純にするために、最初はリポジトリごとに1つのプロジェクトに固執することにしました。ただし、各プロジェクトのリポジトリを配置する場所を決定するのにまだ問題があります。
私はこの質問への回答を確認するのに多くの時間を費やしましたが、その質問の作成者は、リポジトリがEclipseワークスペース内にある場合にのみ、Eclipseを使用してリポジトリを管理できると想定していたと思います。違います。
しかし、その質問について私が最も感銘を受けたのは、1つを除くすべての回答（受け入れられた回答を含む）がリポジトリをEclipseワークスペース内に保持することを提案したのに対し、 EGitユーザーガイドが正反対を推奨していることを指摘した回答は1つだけでした。。
ただし、実際には、Eclipse / EGitによって実装されたアプローチは多数あり、そのうちのいくつかはEGitの推奨事項と矛盾しているように見えます。
たとえば、新しいプロジェクトウィザードを使用してGitから新しいPHPプロジェクトを作成し、リポジトリがリモートの場合、Eclipse / EGitはEclipseワークスペースにプロジェクトフォルダーを作成し、リポジトリ（.git）をプロジェクトフォルダーに配置します。これは、すべてがEclipseワークスペース内にカプセル化されたままになるため、私が実際に望んでいる最終結果です。
ただし、新規プロジェクトウィザードを使用して、ローカルのGitリポジトリーを選択した場合、Eclipse / EGitは、リモートリポジトリーの場合のようにリポジトリーのクローンを作成しません。代わりに、そのリポジトリの作業コピーをプロジェクトの場所として使用し、その場所に.projectおよびその他のメタコンテンツを作成し、その作業コピー内にプロジェクトと同じ名前の新しい（一見不要な）フォルダーを作成します（終了します）。たとえば、 ~/git/blah/blah）。その余分なフォルダーを削除すると、最初の例と同じ構造になります。唯一の違いは、プロジェクトフォルダーがEclipseワークスペースフォルダーのサブフォルダーではなく、ファイルシステム上の別の場所にあることです（例： 。~/git/blah）。このアプローチの唯一の良い点は、EGitユーザーガイドの推奨事項に準拠していることですが、技術的な観点からは、これが最初の例と実際にどのように異なっているかを理解するのは困難です。
これらの不可解な観察を考えると、人々がこれらのアプローチのそれぞれを使用してどのような経験をしたのか、そしてEGitユーザーガイドの推奨事項を無視した場合の落とし穴は何であるのか疑問に思います。