プロジェクトファイルをバージョン管理下に置いておくべきですか？
Eclipse .project、.classpath、.settingsなどのプロジェクトファイルをバージョン管理下で保持する必要がありますか（Subversion、GitHub、CVS、Mercurialなど）？
バージョン管理を維持したい任意のポータブル設定ファイル、
意味：
絶対パスがないファイル。
以下が含まれます：
- 。事業、
- .classpath（絶対パスが使用されない場合、これはIDE変数、またはユーザー環境変数）を使用して可能です
- IDE設定（ここで、「受け入れられた」回答に強く反対します）。多くの場合、これらの設定には静的コード分析ルールが含まれます。これは、このプロジェクトを自分のワークスペースにロードするユーザーが一貫して実施するために非常に重要です。
- IDE固有の設定の推奨事項は、大きなREADMEファイルに記述する必要があります（もちろん、バージョンも変更されています）。
私にとっての経験則：
プロジェクトをワークスペースにロードし、IDEに適切に設定して数分で開始するために必要なすべてのものが含まれている必要があります。
追加のドキュメント、読むべきWikiページなどはありません。
ロードしてセットアップします。
.projectおよび.classpathファイルはい。ただし、バージョン管理でIDE=設定を維持していません。一部のプラグインは、設定の永続化をうまく機能させず、一部の設定は1つの開発マシンからそのため、代わりに、開発者が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のインストールをソース管理に格納することには多くの利点があるとは思いません。プロジェクトファイル、構成、プラグインの設定（特にコードフォーマッタとスタイルルール）-ソース管理に入る必要があります。
追伸Mavenを使用する場合、.projectファイルと.classpathファイルは派生アーティファクトであるという言い方があります。これは、ビルドを実行するたびに生成し、POMから生成した後に手動で微調整する必要がなかった場合（またはいくつかの設定を変更して誤って変更した場合）にのみ当てはまります。
いいえ、ソフトウェアをビルドするために必要なバージョン管理ファイルのみを使用しているためです。さらに、個々の開発者は、独自のプロジェクト固有の設定を持っている場合があります。
いいえ、私は重い Maven ユーザーであり、.projectおよび.classpathを作成および更新する Q for Eclipse プラグインを使用します。プラグインの設定などの他のことについては、私は通常READMEまたはそれに関するWikiページを保持します。
また、私がこれまでに使用したものは、他のIDEがMavenプラグインを使用して、IDE（および自分自身）を満足させるために必要なファイルを生成するだけです）を好みます。
これはすべて意見だと思いますが、長年にわたるベストプラクティスでは、組織全体が1つのIDEで標準化されていない限り、特定のIDEに固有のファイルをソース管理に保存しないことを示しています。切り替えの意図はありません。
どちらにしても、ユーザー設定を保存したくないのは間違いです。また、.projectには、開発者固有の設定を含めることができます。
標準化されたビルドシステムとして、MavenやAntなどを使用することをお勧めします。すべての開発者は、数秒でIDEで構成されたクラスパスを取得できます。
はい。ただし、.settingsフォルダーを除きます。他のファイルをコミットするとうまくいきます。同様の質問 ここ があります。
「生成されたファイルをバージョン管理しない」というアプローチには概ね同意しますが、問題があり、元に戻す必要があります。
注：私は VonCの回答 にも興味があります。特に「Eclipseを数分で起動する」ポイントについては特にそうです。しかし、それは私たちにとって決定的ではありません。
私たちのコンテキストは、m2Eclipseプラグインを使用したEclipse + Mavenです。私たちは、可能な限り共通のディレクトリを持つ共通の開発環境を持っています。しかし、誰かがプラグインを試したり、構成の小さなことを変更したり、別のブランチ用に2番目のワークスペースをインポートしたりすることがあります...
私たちの問題は、Eclipseでプロジェクトをインポートするときに.projectの生成が行われることですが、後で更新されない場合があります。それは悲しいことであり、m2Eclipseプラグインが改善されるため、おそらく永続的ではありませんが、今はそれが本当です。したがって、構成が異なることになります。 いくつかの性質がいくつかのマシンの多くのプロジェクトに追加され、その後、動作が大きく異なりました:
唯一の解決策は、.projectファイルをバージョン管理することです（リスクを回避するために、.classpathと.settingsについても同じことを行います）。そうすることで、ある開発者がpomを変更すると、ローカルファイルがm2Eclipseを使用して更新され、それらすべてが一緒にコミットされ、他の開発者はすべての変更を確認できます。
注：この例では相対ファイル名を使用しているため、これらのファイルを共有しても問題はありません。
だから、あなたの質問に答えるために、私ははい、それらのファイルをコミットします。
私も好きでした：
- リッチセラーの---（answer
はい。ビルド出力以外のすべて。
これらのプロジェクトファイルは、プロジェクトの作業中に時間とともに変化する可能性があるため、バージョン管理下に置いています。
IntelliJ IDEAを使用し、プロジェクト（.ipr）およびモジュール（.iml）ファイルの「.sample」バージョンをバージョン管理下に置いています。
ここでやや大きいのは、バージョン管理よりも共有と再利用です。ただし、これらの構成を共有する場合は、他のすべてのもののすぐ隣に、リポジトリよりも配置するのに適しています。
共有およびバージョン管理されたプロジェクトファイルのいくつかの利点：
- タグ/ブランチをチェックアウトして、すぐに作業を開始できます
- 新規開発者が最初に開発環境をセットアップし、速度を上げることが容易になります
- これは、常に非常に満足できるDRYに忠実です。その前に、all開発者はこれらのことを時々設定し、基本的に繰り返し作業を行わなければなりませんでした。もちろん、誰もが自分自身を繰り返すのを避けるための独自の小さな方法がありましたが、チーム全体を見ると、多くの重複した努力がありました。
IDEA=では、これらのファイルには、「ソース」および「テストソース」ディレクトリとは何か、外部依存関係に関するすべて（ライブラリjarが存在する場所、関連するソースまたはjavadocs）;ビルドオプションなど。これはしないものです開発者によって異なります（私は this に同意しません） IDEAはより個人的なIDE設定を他の場所に保存します。また、プラグイン構成も保存します（Eclipseについてはよくわかりません。これは、まったく違いはありません。）
私は同意します この答え それは言う：
プロジェクトをワークスペースにロードして、IDEで適切に設定するために必要なすべてのものが揃っていて、数分で作業を開始できる必要があります。[...]ロードしてください。それを設定して、行きます。
そして、バージョン管理されたプロジェクトファイルのおかげで、このようになっています。