IDEプロジェクトのリポジトリに何を含める必要があるか

この場合はNetbeansで作成されたプロジェクトを追加したいのですが、この質問はほとんどのIDEで一般的です。それは単に、リポジトリに何を含めるべきかということです。たとえば、Netbeansはnbprojectフォルダーを作成し、eclipseは.settingsフォルダーを作成します。これらをリポジトリに含めた場合、プロジェクト固有の設定を含めるか含めないことの利点/欠点は何ですか。

この場合、それは個人的なプロジェクトなので、他の人がプロジェクトに取り掛かることはないと思いますが、最小限のプロジェクト設定を追加して、プロジェクト自体が別のマシンで簡単に作業を開始できるようにするとよいでしょう。

それは本当にそれがどのようなデータであるかに依存し、おそらく個々のファイルについてさえ、ケースバイケースで決定されるべきです。それらのファイルの内容を見てください。多くの場合、あなたは彼らが何を意味するかを言うことができます。IDEのウィンドウの位置やサイズのようなものは、ソース管理では必要ありません。

ただし、一部のIDEプロジェクトファイルは重要なプロジェクトメタデータです。私はNetbeansをよく知りませんが、Eclipseの場合、.projectファイルはIDEにプロジェクトの名前、Java Webプロジェクトなどであることを伝え、.classpathファイルにはソースフォルダーとライブラリに関する情報が含まれています。.settingsディレクトリ内のいくつかのファイルも同様に重要です。たとえば、org.eclipse.core.resources.prefsには、どのファイルにどのエンコーディングを使用する必要があるかに関する情報が含まれています。

プロジェクトのメタデータとして、これはソース管理でバージョン管理するに値するものです。

一部のIDEは、他のIDEからプロジェクトメタデータをインポートできます。特定のIDEに関連付けられていない形式にすることをお勧めします。

Javaには、Mavenのようなものがあります。これは、プロジェクトの構造に強力な規則を課し、プロジェクトのメタデータ（ライブラリの依存関係など）を1点（プロジェクトのメインディレクトリにあり、もちろんソース管理にあるpom.xmlと呼ばれるファイル）で指定できます。その後、Maven構成からIDEプロジェクトファイルを作成するプラグインと、プロジェクトのビルドプロセスを自動化したり、ほとんど何でもできるプラグインがあります。場合によっては、物事が不必要に複雑になり、習得に時間がかかるように感じることがありますが、そのメリットは一般的に価値があります。

これは、リポジトリにどのような情報を保持したいかによります。コミット時に開いていて編集していたファイルまですべてが必要で、リポジトリを使用しているのがあなただけの場合は、先に進んですべてをコミットしますが、別のマシンでは機能しない可能性があることに注意してください。 。

同じIDEを使用していない他のユーザーとコードを共有できるようにしたい場合は、プロジェクト固有の実装なしでコード自体をコミットしてください。

全員が同じIDEを使用していることがわかっている場合は、おそらくコンピューター固有ではないもの、つまりIDE自体の設定ファイル/フォルダーを含めることができます。これにより、プロジェクトをプロジェクトとしてインポートできるようになります。 IDEはそれを期待しています。

開発に役立ち、ビルド/リリースまたはプロジェクト自体に役に立たないアーティファクトは含めないでください。リポジトリはクリーンで整頓されている必要があり、環境に関係なく、プロジェクトに関連するものだけが含まれている必要があります。リポジトリはあなたの習慣を認識していないはずです。そして第二に、それに似たようなことをすると不必要にあなたを悩ませgit statusます... しかし、ちょっと私は変更を加えたことはありません...ああ、それを無視してください。

より実用的な例を挙げましょう（gitここではツールとして使用します）。

メインリポジトリ内の（再帰的な）サブモジュールにIDE固有のもの（メインプロジェクト環境にも干渉する可能性があります）が必要になることはありません。現在のプロジェクト内での使用。それが開発された環境ではありません。おそらく、他の誰かにもそれをしたくないでしょう。

別のマシンで設定を使用できるようにするには、IDE内を掘り下げて、IDEがそのようなことに対してどのようなサポートを提供するかを確認することをお勧めします。EmacsにはinitEmacsサーバーもあります。または.sh、セットアップを自動的に行うカスタムマクロまたはスクリプト（）を作成することもできます。

個人的なプロジェクトの場合は、設定をソース管理に保存します。個人的には、開発環境を再度セットアップすることほど、プロジェクトのモチベーションを損なうものはありません。

より多くの人々が関わっているとき、私はこれらのものをソース管理に入れません。私のチームでは、IntelliJ、Sublime Text、Eclipseを使用しています。IDEファイルは混乱を増すだけで、他の人からそれらのファイルへのコミットを、使用していないIDEに引き込む結果になります。

また、プロジェクトはIDEに依存するべきではありません。ビルドサーバーは、製品をコンパイルするためにEclipseを起動しないため、すでにIDEは含まれていないはずです。よりマイナーなポイント：プロジェクト内の個人的な組織を排除します。たとえば、IntelliJでは、プロジェクト内で多くのモジュールを使用します。.iml（モジュール）ファイルを保存しないため、IntelliJを使用している他の誰もこれについて心配しません。

チームが同じIDEを使用している場合はそれが適していますが、絶対パスを使用しているため、誰かが不正な.classpathエントリをコミットします。これで、IDEを使用するすべての人が心配します。

もちろん、欠点は、誰かがプロジェクトをチェックアウトするときにセットアップが増えることです。価値があると思います。私たちは依存関係の管理にIvyを使用しており、セットアップや依存関係などに関する情報を持っています。この先行投資にもかかわらず、IDEの設定をソース管理から除外することは価値があると思います。