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と呼ばれるファイル）で指定できます。次に、IDEプロジェクトファイルをMaven構成から作成するプラグインや、プロジェクトのビルドプロセスを自動化したり、ほとんど何でもできるプラグインがあります。場合によっては、物事を不必要に複雑にして、学ぶのに少し時間がかかりますが、利点は一般的にそれだけの価値があります。
これは、リポジトリにどのような種類の情報を保持したいかによります。コミット時に開いていて編集していたファイルまですべてが必要であり、リポジトリを使用しているのがあなただけである場合は、先に進んですべてをコミットしますが、別のマシンでは機能しない可能性があることを知ってください。 。
同じIDEを使用していない他のユーザーとコードを共有できるようにしたい場合は、プロジェクト固有の実装なしでコード自体をコミットしてください。
誰もが同じIDEを使用していることがわかっている場合は、おそらくコンピュータ固有ではないものを含めることができます。つまり、IDE自体の設定ファイル/フォルダです。 IDEはそれを期待しているので、プロジェクトをインポートする機能があります。
developmentを支援するアーティファクトで、ビルド/リリースまたはプロジェクト自体には役に立たないnotを含める必要があります。リポジトリはクリーンで整頓されている必要がありますyour environmentではなく、プロジェクトに関連するものだけが含まれている必要があります。リポジトリはあなたの習慣を認識していないはずです。次に、git statusに似た操作を行うと、不必要にバグが発生します... ただし、変更を加えたことはありません...無視してください
より実用的な例を挙げましょう（githereをツールとして使用します）：
メインのリポジトリ内の（再帰的な）サブモジュールにIDE特定の要素（メインのプロジェクト環境にも干渉する可能性があります））を持たせたくないのは、作成したコードだけだからです。他の誰か（またはあなた）が現在のプロジェクト内で使用しています。開発された環境ではありません。おそらく他の人にもそれをしたくないでしょう。
別のマシンで設定を使用できるようにするには、IDEを掘り下げて、そのようなものに対してどのようなサポートが提供されるかを確認してください。EmacsにはinitとEmacsサーバーもあります。または自動的に設定を行うカスタムマクロまたはスクリプト（.sh）を作成できます。
個人的なプロジェクトの場合は、設定をソース管理に保存します。個人的には、開発環境を再度セットアップすることほど、プロジェクトのモチベーションを損なうものはありません。
より多くの人が関わっているとき、私はこれらのものをソース管理に入れません。私のチームでは、IntelliJ、Sublime Text、Eclipseを使用しています。 IDEファイルは混乱を増すだけで、他の人からこれらのファイルへのコミットをプルすることになりますIDE使用しません。
また、プロジェクトはIDEに依存している必要はありません。ビルドサーバーは、製品をコンパイルするためにEclipseを起動しないので、すでにIDEを含まないはずです。ポイント：プロジェクト内の個人的な組織を排除します。たとえば、IntelliJでは、プロジェクト内で多くのモジュールを使用したいのですが、.iml（モジュール）ファイルを格納しないため、IntelliJを使用している他の誰もこれについて心配しません。
あなたのチームが同じIDEを使用している場合、それはより良いことですが、絶対パスを使用したため、誰かが不正な.classpathエントリをコミットします。今、IDE =それが心配です。
確かに、欠点は、誰かがプロジェクトをチェックアウトするときにセットアップが増えることです。価値があると思います。依存関係の管理には Ivy を使用しており、セットアップ、依存関係などに関する情報を持っています。この初期費用にもかかわらず、IDE設定をソースから除外することは価値があると思いますコントロール。