複数のJavaプロジェクトを含むEclipseワークスペースにEclipse RCPアプリケーション用のコードがあります。私たちはMercurialを単純な.hgignore * * .classで使用しています（しかし、同じ問題はGitに関係します）。Git/MercurialでEclipseプロジェクトの.metadataを無視しても問題ありませんか？
コードを少し変更しても、.metadataのファイルの多くが変更される可能性があります。
バージョンコントロールから.metadataの一部またはすべてを除外したいと思います。完全に除外すると、作業領域が失われます。
私たちが安全に除外できるものは誰も知っていますか？あるいは、コードを新鮮なコンピュータにプルダウンすれば、どのように再作成できますか？
ファイルは、次のとおりです。
どこかは、私はかなりあるいくつかのEclipse関連のツールをテストするために使用Eclipseワークスペースを持っていますひどく切った、b utは動作します。私がそれを掘り出すことができるかどうかがわかります。
ありがとう！それはちょうど約働いた。 .metadata \ .plugins \ org.eclipse.core.resources \ .rootと.safetableも保持する必要がありました。 –
.metadata/.plugins/org.eclipse.wst.jsdt.core/variablesAndContainers.datも追加する必要がありました。 –
実際には、ワークスペースのメタデータをソース管理で保持すべきではありません。基本的なワークスペース構成はteam project setで共有できます。私は個人的に承知している
ありがとうございます - 有望です。私はそれを試してみる。 –
プロジェクトセットファイルには、チェックアウトするプロジェクトと、どこから他のものを含むかが含まれます。私はあなたに同意していません - 私は作業の最も慎重な方法はコードとプロジェクトごとのメタデータをチェックし、ワークスペースをローカルコントロールの下に置くことだと思います - もしOPがワークスペース設定を共有しようとするなら、 PSF以上のものが必要です。 –
トムは正しいです。それは私のために働かなかった。 PSFには、私が接続できないCVSリポジトリ（誤って設定されていて存在しない）への参照が含まれています。 –
私は日常的に.projectと.classpathを保持しているだけでなく、gitでは安全ですが便利です。
.classと.settingsは私のgitignoreにあります。それらはそれぞれ生成され、個人固有のものです。
github eclipse ignoreにはまだ.projectと.classpathが含まれています。 – lanoxx
github eclipse ignoreには.project（少なくとも今のところ）、.cprojectのみが含まれていません。 –
GitHubには、カタログは様々なプラットフォーム、エディタや言語のための無視のためのファイル仕様提案コミュニティ「gitignore」プロジェクト維持されます。https://github.com/github/gitignore
Eclipseの無視はここにある：https://github.com/github/gitignore/blob/master/Global/Eclipse.gitignore
（つまり、これら他のファイル仕様がある場合彼らは知っている、知っておくべき！）
優れたプロジェクトです！その特定の無視リストには2つの問題があります：1つは、.classpathのようにチェックインしたいことを間違いなく無視し、もう1つはプロジェクトディレクトリ内のものについてですが、OPは全体のワークスペース。そのリストをワークスペースに適用した場合、.metadataディレクトリ全体が無視されるため、プロジェクトの.locationファイルのような重要な要素が失われてしまいます。しかし、ここでの問題は、権威と派生ファイルを非常に役に立たない方法で混ぜるEclipseです。 –
メタデータとワークスペース
I WOU .metadataフォルダを共有しないでください。実際には、特別な理由がなければ、私はワークスペースフォルダを共有することなく、gitを使って各プロジェクトを個別に共有します。その方法は、.metadataフォルダは常にあなたのgitリポジトリの親フォルダになり、あなたはとにかくそれを無視する必要があるかどうかを考えるために持っていけない：おそらく
あなたがすべき具体的な
|-- workspace/
| \-- .metadata/
| |-- yourProjectOne/
| | \-- .git/
| | |-- .project
| | |-- src/
| | |-- ...
| |-- yourProjectTwo/
| | \-- .git/
| | |-- .project/
| | |-- src/
| | |-- ...
プロジェクト常に.projectファイルを共有し、.settings/ファイルを共有しないでください。 .classpathはあなたの環境に依存するかもしれませんが、それは競合を引き起こす可能性があるため（例えば、1人のユーザがopenjdkを使用し、もう1人がsun-jdkを使用する場合など）、共有することはお勧めしません。.settingsには、Eclipseの環境設定と設定が含まれているため、共有する必要はありません。 gitからクローンを作成した後にプロジェクトを適切にインポートすると、問題はありません。
eclipse documentation状態が.projectファイルについては、次の
このファイルの目的は、プロジェクトの自己記述をすることですので、 アップzip形式で圧縮またはサーバーに放出されるプロジェクトができること は別のワークスペースで正しく再作成されます。
と：
新しいプロジェクトが既存の プロジェクト記述ファイルが含まれている場所に作成されている場合は、その記述ファイルの内容は、プロジェクトの説明として表彰さ ます。ただし、作成中のプロジェクトの名前 と一致しない場合、ファイル内の プロジェクト名は無視されます。ディスク上の記述ファイルが であれば、プロジェクトの作成は失敗します。
は、私もこれは依存関係の管理であなたに多くの問題を節約するようにMavenを使用することをお勧めして
Mavenを.classpath
Mavenプロジェクトとの主な違いは、あなたができることですプロジェクトをMaven - > "Existing Maven Projects"としてインポートし、pom.xmlと.projectファイルをgitで共有する必要があります。 Eclipseは自動的に.classpath, .settings/ファイルを作成します。したがって、明らかにそれらを共有する必要はありません。 pom.xmlに何か変更があった場合は、Maven - > "Update project configuration"とMaven - > "Update dependencies"を実行するだけです。 Mavenのなし
あなたは.projectファイルではなく.settings/フォルダを共有する必要があります。あなたは.classpathを共有することを考慮することができますが、上で説明したように競合が発生する可能性があります。私もそれを共有しないことをお勧めします。日食>「ワークスペースから既存のプロジェクト」.projectファイルを称えるが、.classpathと.settings/ファイルを再作成します - あなたは、単にインポートを使用することができますgitリポジトリをクローン化した後
：プロジェクトをインポートするには、以下の方法を使用します。インポート後、Eclipseからクラスパスを手動で設定する必要があります（チームが別のライブラリを使用するたびに）。
.projectファイルを共有しないと、Eclipseを使用してプロジェクトをインポートすることはできません。最初にプロジェクトウィザードを使用して新しいプロジェクトを作成し、「一般 - >ファイルシステム」を選択する必要があります。これにより、すべてのファイルがワークスペースにコピーされます。 gitリポジトリをワークスペースにクローン化することはできないので、別の場所でクローンしてそこからインポートする必要があるため、これはおそらくあなたが望むものではありません。したがって、常に.projectファイルを共有する必要があります。
この説明の提案がある場合、またはそれに同意しない場合は、お待ちください。私はこれが1つまたは他のものを助けることを望む。
Eclipseワークスペース全体を1つのMercurialリポジトリに格納していることを理解していますか？それぞれのプロジェクトをリポジトリに保存し、傘のリポジトリのサブリポジトリとしてグループ化して、一緒にバージョンアップすることができましたか（Eclipseにサポートがあるかどうかはわかりませんが） –
プラグインベースの製品で、別々のプロジェクトごとにプラグインが定義されています。すべて一緒に、または全体の製品が必要です。したがって、個々のプロジェクトは全体の一部にすぎません。そのため、Eclipseワークスペース全体を1つのリポジトリに格納する必要があります。 –