Eclipseの.project、.classpath、.settingsなどのプロジェクトファイルをバージョン管理下（Subversion、GitHub、CVS、Mercurialなど）に保持する必要がありますか？
回答:
ポータブル設定ファイルをバージョン管理で保持する必要があります。
つまり
、絶対パスが含まれていないファイルです。
以下が含まれます：
私の経験則：
プロジェクトをワークスペースにロードし、IDEで適切に設定して数分で作業を開始するために必要なすべてのものが揃っていなければなりません。
追加のドキュメント、読むべきWikiページなどはありません。
それをロードし、セットアップし、行ってください。
.projectおよび.classpathファイルはい。ただし、バージョン管理でIDE設定を維持しません。いくつかのプラグインは、設定の永続化がうまく機能しない場合があり、一部の設定は、開発マシン間で移植性が低いことがわかりました。そのため、代わりに、開発者がIDEをセットアップするために必要な手順を強調するWikiページがあります。
これらは私が生成されたファイルと見なすものであり、バージョン管理下に置くことは決してありません。たとえば、人々が異なるEclipseプラグインをインストールしている場合などは、マシンごと、開発者ごとに異なる可能性があります。
代わりに、新しいチェックアウト時にこれらのファイルの初期バージョンを生成できるビルドツール（Maven）を使用します。
ここで2つのオプションの間で引き裂かれています。
一方では、すべてのソースアーティファクトがバージョン管理に保存されており、ビルドスクリプト（ANTまたはMavenなど）が標準への準拠を保証している限り、誰もが最も生産性の高い開発ツールのセットを自由に使用できるはずだと思います使用するJDK、依存するサードパーティライブラリのバージョン、スタイルチェックの実行（checkstyleなど）、ユニットテストの実行などを正確に指定します。
一方、私は非常に多くの人々が同じツール（Eclipseなど）を使用していると思います。多くの場合、ビルド時ではなく設計時に標準化した方がはるかに優れています。たとえば、CheckstyleはEclipseプラグインとしてよりもはるかに便利ですANTまたはMavenのタスク-開発ツールのセットとプラグインの一般的なセットで標準化することをお勧めします。
私は、全員がまったく同じJDK、同じバージョンのMaven、同じバージョンのEclipse、同じセットのEclipseプラグイン、および同じ構成ファイル（たとえば、Checkstyleプロファイル、コードフォーマッタールールなど）を使用するプロジェクトに取り組みました。これらはすべて、ソース管理（.project、.classpath、および.settingsフォルダー内のすべて）に保持されていました。依存関係やビルドプロセスを継続的に微調整しているプロジェクトの初期段階で、それは本当に楽になりました。また、プロジェクトに新しいスターターを追加する際にも非常に役立ちました。
要するに、宗教戦争の可能性がそれほど多くない場合は、開発ツールとプラグインの基本セットで標準化し、ビルドスクリプトでバージョンのコンプライアンスを確保する必要があると思います（たとえば、Javaバージョンを明示的に指定することによって）。 JDKとEclipseインストールをソース管理に格納することには多くの利点があるとは思わないでください。プロジェクトファイル、構成、プラグインの設定（特にコードフォーマッタとスタイルルール）を含む、派生アーティファクト以外のすべてのものは、ソース管理に含める必要があります。
PS Mavenを使用している場合、.projectファイルと.classpathファイルは派生アーティファクトであるという言い方があります。これは、ビルドを実行するたびに生成し、POMから生成した後に手動で微調整する必要がなかった場合（または、いくつかの設定を変更して誤って変更したことがない場合）にのみ当てはまります。
いいえ、私はMavenのヘビーユーザーであり、Q for Eclipseを使用しています .projectと.classpathを作成および更新プラグインをいます。プラグインの設定など、他のことについては、私は通常、READMEまたはWikiページでそれについて説明します。
また、私がこれまでに使用したものは、他のIDEがMavenプラグインを使用して、IDE（および自分自身）を満足させるために必要なファイルを生成することを好んでいます。
「生成されたファイルをバージョン管理しない」というアプローチには概ね同意しますが、問題があり、元に戻す必要があります。
注：私はVonCの回答、特に「Eclipseを数分で起動する」ポイントについても興味があります。しかし、それは私たちにとって決定的ではありません。
私たちのコンテキストは、m2eclipseプラグインを使用するEclipse + Mavenです。私たちは、可能な限り共通のディレクトリを持つ共通の開発環境を持っています。しかし、誰かがプラグインを試したり、設定の小さなことを変更したり、別のブランチ用に2番目のワークスペースをインポートしたりすることがあります...
私たちの問題は、プロジェクトをEclipseにインポートするときに.projectの生成が行われるが、後ですべての場合に更新されるわけではないことです。それは悲しいことであり、m2eclipseプラグインが改善されるため、おそらく永続的ではありませんが、今は本当です。したがって、構成が異なることになります。私たちが今日持っていたのは、いくつかの性質がいくつかのマシンの多くのプロジェクトに追加され、その後、大きく異なる動作をしたことです :-(
私たちが目にする唯一の解決策は、.projectファイルをバージョン管理することです（リスクを回避するために、.classpathと.settingsについても同じことを行います）。そうすることで、ある開発者がpomを変更すると、ローカルファイルがm2eclipseを使用して更新され、それらすべてが一緒にコミットされ、他の開発者はすべての変更を確認できます。
注：この例では、相対ファイル名を使用しているため、これらのファイルを共有しても問題はありません。
だから、あなたの質問に答えるために、私ははい、それらのファイルをコミットします。
私も好きでした：
IntelliJ IDEAを使用し、プロジェクト（.ipr）およびモジュール（.iml）ファイルの「.sample」バージョンをバージョン管理下に置いています。
ここでやや大きいのは共有と再利用です、バージョニングよりもです。ただし、これらの構成を共有する場合は、他のすべての隣に、リポジトリよりも配置するのに適した場所があります。
共有およびバージョン管理されたプロジェクトファイルのいくつかの利点：
IDEAでは、これらのファイルには次のような構成が含まれていることに注意してください。「ソース」および「テストソース」ディレクトリは何ですか。外部依存関係に関するすべて（ライブラリjarの場所、関連するソースまたはjavadocsがある場所）; ビルドオプションなど。これは開発者ごとに変わらないものです（私はこれに同意しませんかなり）。IDEAは、プラグイン構成だけでなく、より個人的なIDE設定を他の場所に保存します。（私はEclipseをよく知りません。これはまったく異なる場合と異なる場合があります。）
私は言うこの答えに同意します：
プロジェクトをワークスペースにロードし、IDEでプロジェクトを適切に設定して数分で作業を開始するために必要なすべてのものが揃っていなければなりません。[...]ロードして、セットアップして、実行します。
そして、バージョン管理されたプロジェクトファイルのおかげで、このようになっています。