Eclipse の .project、.classpath、.settings などのプロジェクト ファイルをバージョン管理下 (Subversion、GitHub、CVS、Mercurial など) に保持する必要がありますか?
cretzel
質問する
18142 次
12 に答える
96
ポータブル設定ファイルをバージョン管理し続けたいと思います。
つまり
、絶対パスが含まれていないファイルです。
これには以下が含まれます：
- 。事業、
- .classpath（絶対パスが使用されていない場合、IDE変数またはユーザー環境変数を使用して可能）
- IDE設定（これは私が「受け入れられた」答えに強く反対するところです）。これらの設定には、多くの場合、このプロジェクトを自分のワークスペースにロードするすべてのユーザーに一貫して適用するために非常に重要な 静的コード分析ルールが含まれています。
- IDE固有の設定に関する推奨事項は、大きなREADMEファイルに書き込む必要があります（もちろんバージョン管理も必要です）。
私の経験則：
プロジェクトをワークスペースにロードし、IDEで適切にセットアップして数分で実行するために必要なすべてのものをその中に含めることができなければなりません。
追加のドキュメント、読むべきwikiページなどはありません。
それをロードし、セットアップし、行きます。
于 2008-09-23T06:25:25.423 に答える
30
.project および .classpath ファイル はい。ただし、IDE 設定をバージョン管理に保持しません。いくつかのプラグインは設定を永続化するのにうまく機能せず、一部の設定はある開発マシンから次の開発マシンへの移植性があまり高くないことがわかりました。そのため、代わりに、開発者が IDE をセットアップするために必要な手順を強調する Wiki ページを用意しています。
于 2008-09-22T17:12:44.707 に答える
18
これらは生成されたファイルであると考えているため、バージョン管理下に置くことはありません。たとえば、さまざまな Eclipse プラグインがインストールされている場合など、マシンごと、開発者ごとに異なる可能性があります。
代わりに、新しいチェックアウトを行うときにこれらのファイルの初期バージョンを生成できるビルド ツール (Maven) を使用します。
于 2008-09-22T17:13:38.930 に答える
7
ここで 2 つの選択肢の間で迷っています。
一方で、すべてのソース アーティファクトがバージョン管理に保存され、ビルド スクリプト (ANT や Maven など) が標準への準拠を保証する限り、誰もが最も生産性の高い一連の開発ツールを自由に使用できるべきだと思います。使用するJDK、依存するサードパーティライブラリのバージョン、スタイルチェック（checkstyleなど）の実行、ユニットテストの実行などを正確に指定します。
一方で、非常に多くの人が同じツール (Eclipse など) を使用していると思いますが、多くの場合、ビルド時ではなく設計時に標準化した方がはるかに優れています。 ANT または Maven タスク - 一連の開発ツールと共通の一連のプラグインで標準化する方がよいこと。
私は、誰もがまったく同じ JDK、同じバージョンの Maven、同じバージョンの Eclipse、同じセットの Eclipse プラグイン、および同じ構成ファイル (Checkstyle プロファイル、コード フォーマッタ ルールなど) を使用するプロジェクトに取り組みました。これらはすべてソース管理に保管されていました - .project、.classpath、および .settings フォルダー内のすべて。プロジェクトの初期段階で、人々が依存関係やビルド プロセスを継続的に微調整していたときに、作業が非常に楽になりました。また、プロジェクトに新しいスターターを追加する際にも非常に役立ちました。
結局のところ、宗教戦争の可能性があまりないのであれば、開発ツールとプラグインの基本セットを標準化し、ビルド スクリプトでバージョン コンプライアンスを確保する必要があると思います (たとえば、Java のバージョンを明示的に指定するなど)。 JDK と Eclipse のインストールをソース管理に保存することに大きなメリットがあるとは思わないでください。プロジェクト ファイル、構成、プラグイン設定 (特にコード フォーマッタとスタイル ルール) など、派生アーティファクトではないものはすべて、ソース管理に移動する必要があります。
PS Maven を使用する場合、.project ファイルと .classpath ファイルは派生アーティファクトであるという議論があります。これは、ビルドを行うたびにそれらを生成し、POM から生成した後に手動で微調整する必要がなかった場合 (または、いくつかの設定を変更して誤って変更したことがない場合) にのみ当てはまります。
于 2008-09-23T09:56:21.033 に答える
6
いいえ、ソフトウェアのビルドに必要なバージョン管理ファイルのみを使用しているためです。さらに、個々の開発者は、独自のプロジェクト固有の設定を持っている場合があります。
于 2008-09-22T18:27:17.677 に答える
5
これはすべての意見だと思いますが、長年にわたるベストプラクティスでは、組織全体が1つのIDEで標準化されており、切り替えの意図がない場合を除いて、特定のIDEに固有のファイルをソース管理に保存しないでください。
いずれにせよ、ユーザー設定を保存したくないことは間違いありません。.projectには、実際に開発者固有の設定を含めることができます。
標準化されたビルドシステムとして、MavenやAntなどを使用することをお勧めします。開発者なら誰でも、数秒でIDEにクラスパスを設定できます。
于 2008-09-23T04:50:31.097 に答える
1
はい、.settings フォルダーを除きます。他のファイルをコミットするとうまくいきます。ここに同様の質問があります。
于 2008-09-22T17:06:57.153 に答える
1
「生成されたファイルをバージョン管理しない」というアプローチには概ね同意しますが、問題があり、元に戻す必要があります。
注: VonC の回答、特に「数分で Eclipse を起動する」ポイントについても興味があります。しかし、それは私たちにとって決定的なものではありません。
私たちのコンテキストは、m2eclipse プラグインを使用した Eclipse+Maven です。可能な限り共通のディレクトリを持つ共通の開発環境があります。しかし、誰かがプラグインを試したり、設定を少し変更したり、別のブランチ用に 2 つ目のワークスペースをインポートしたりすることがあります...
私たちの問題は、プロジェクトを Eclipse にインポートするときに .project の生成が行われるが、後で更新されるとは限らないことです。悲しいことに、m2eclipse プラグインが改善されるため、おそらく永続的ではありませんが、現時点では真実です。そのため、最終的にはさまざまな構成になります。今日私たちが持っていたのは、いくつかの性質がいくつかのマシン上の多くのプロジェクトに追加され、その後大きく異なる動作をしたことです:-(
唯一の解決策は、.project ファイルをバージョン管理することです(リスクを回避するために、.classpath と .settings についても同じことを行います)。そうすれば、ある開発者が自分の pom を変更すると、m2eclipse を使用してローカル ファイルが更新され、すべてが一緒にコミットされ、他の開発者はすべての変更を確認できます。
注 : この場合、相対ファイル名を使用しているため、これらのファイルを共有しても問題ありません。
したがって、あなたの質問に答えるには、はい、それらのファイルをコミットしてください。
私も好きでした：
- リッチセラーの答え
于 2009-10-28T17:05:32.380 に答える
0
これらのプロジェクト ファイルは、プロジェクトに取り組んでいるうちに時間の経過とともに変更される可能性があるようです。そのため、バージョン管理下に置いています。
于 2008-09-22T17:06:31.537 に答える
0
はい。ビルド出力以外のすべて。
于 2008-10-15T06:33:00.840 に答える