Java 我可以在 Git/Mercurial 中安全地忽略 Eclipse 项目 .metadata 中的哪些内容？

What of Eclipse project .metadata can I safely ignore in Git/Mercurial?

提问by Irish Buffer

We have the code for an Eclipse RCP application in an Eclipse workspace containing multiple Java projects. We are using Mercurial with a simple .hgignore just *.class (but the same issue would pertain to Git).

我们在包含多个 Java 项目的 Eclipse 工作区中有 Eclipse RCP 应用程序的代码。我们使用 Mercurial 和一个简单的 .hgignore 只是 *.class（但同样的问题也适用于 Git）。

Even a small change to the code can result in many of the files in .metadata getting changed.

即使对代码进行很小的更改也会导致 .metadata 中的许多文件发生更改。

I'd like to exclude some or all of the .metadata from version control. If we exclude it completely, the workspace is lost.

我想从版本控制中排除部分或全部 .metadata。如果我们完全排除它，工作空间就会丢失。

Does anyone know what we can safely exclude? Alternatively, how can we recreate it if we pull the code down to a fresh computer?

有谁知道我们可以安全地排除什么？或者，如果我们将代码拉到新的计算机上，我们如何重新创建它？

采纳答案by Tom Anderson

The files i'm personally aware of are:

我个人知道的文件是：

• version.ini (not very exciting)
• .plugins/org.eclipse.jdt.core/variablesAndContainers.dat (classpath variables)
• .plugins/org.eclipse.core.resources/.projects/*/.location (projects in the workspace)

• version.ini（不是很令人兴奋）
• .plugins/org.eclipse.jdt.core/variablesAndContainers.dat（类路径变量）
• .plugins/org.eclipse.core.resources/.projects/*/.location（工作区中的项目）

Somewhere, i have an Eclipse workspace used for testing some Eclipse-related tools that is pretty severely cut down, but works. I'll see if i can dig it out.

在某处，我有一个 Eclipse 工作区，用于测试一些与 Eclipse 相关的工具，这些工具被严重削减，但有效。我看看能不能挖出来

回答by Michael Borgwardt

The workspace metadata really shouldn't be kept in source control. The basic workspace configuration can be shared via a team project set.

工作区元数据真的不应该保留在源代码管理中。基本工作区配置可以通过团队项目集共享。

回答by NorthIsUp

I routinely keep .project and .classpath, not only are they safe for git but useful.

我经常保留 .project 和 .classpath，它们不仅对 git 安全而且很有用。

.class and .settings are in my gitignore. Those are generated and person specific respectively.

.class 和 .settings 在我的 gitignore 中。这些分别是生成的和特定于个人的。

回答by Adam Vandenberg

GitHub is maintaining a community "gitignore" project that catalogs suggested filespecs for ignores for various platforms, editors and languages: https://github.com/github/gitignore

GitHub 正在维护一个社区“gitignore”项目，该项目对各种平台、编辑器和语言的建议文件规范进行分类：https: //github.com/github/gitignore

Eclipse ignores are here: https://github.com/github/gitignore/blob/master/Global/Eclipse.gitignore

Eclipse 忽略在这里：https: //github.com/github/gitignore/blob/master/Global/Eclipse.gitignore

(If there are other filespecs that they should know about, let them know!)

（如果他们应该知道其他文件规范，请告诉他们！）

回答by lanoxx

Metadata and Workspace

元数据和工作区

I would never share the .metadatafolder. In fact unless you have a particular reason I would not even share the workspace folder but instead share each project separately with git. That way the .metadatafolder will always be in the parent folder of your git repository and you dont have to think about whether you need to ignore it anyway:

我永远不会共享.metadata文件夹。事实上，除非您有特殊原因，否则我什至不会共享工作区文件夹，而是与 git 单独共享每个项目。这样.metadata文件夹将始终位于 git 存储库的父文件夹中，您不必考虑是否需要忽略它：

|-- workspace/
|  \-- .metadata/
|  |-- yourProjectOne/
|  |  \-- .git/
|  |  |-- .project
|  |  |-- src/
|  |  |-- ...
|  |-- yourProjectTwo/
|  |  \-- .git/
|  |  |-- .project/
|  |  |-- src/
|  |  |-- ...

Project Specific

项目特定

You should probably always share the .projectfile and never .settings/files. The .classpathmay depend on your environment but I would not suggest to share it either, because it can cause conflicts (for example if one user uses openjdk and the other uses sun-jdk. The .settingscontains preferences and settings for eclipse and changes a lot, thus it should not be shared. If you properly import the project after you cloned it from git then you will also not have any problems.

您可能应该始终共享.project文件而不是.settings/文件。这.classpath可能取决于您的环境，但我也不建议共享它，因为它可能会导致冲突（例如，如果一个用户使用 openjdk 而另一个用户使用 sun-jdk。其中.settings包含 eclipse 的首选项和设置并且更改了很多，因此它不应该被共享。如果你在从 git 克隆之后正确导入项目，那么你也不会有任何问题。

The eclipse documentationstates the following about the .projectfile:

在Eclipse文档指出有关下列.project文件：

The purpose of this file is to make the project self-describing, so that a project that is zipped up or released to a server can be correctly recreated in another workspace.

此文件的目的是使项目具有自描述性，以便可以在另一个工作区中正确地重新创建压缩或发布到服务器的项目。

and:

和：

If a new project is created at a location that contains an existing project description file, the contents of that description file will be honoured as the project description. One exception is that the project name in the file will be ignored if it does not match the name of the project being created. If the description file on disk is invalid, the project creation will fail.

如果在包含现有项目描述文件的位置创建新项目，则该描述文件的内容将被视为项目描述。一种例外情况是，如果文件中的项目名称与正在创建的项目名称不匹配，则会被忽略。如果磁盘上的描述文件无效，则项目创建将失败。

I also suggest to use Maven as this will save you a lot of problems with the dependency management and .classpath

我还建议使用 Maven，因为这将为您节省很多依赖管理和 .classpath 的问题

Maven

马文

The main difference with a Maven project is that you can import the project as Maven->"Existing Maven Projects" and thus only need to share the pom.xml and .projectfile in git. Eclipse will then create the .classpath, .settings/files for you automatically. Thus obviously you dont need to share them. If something changes in pom.xml you simply run Maven->"Update project configuration" and Maven->"Update dependencies".

与 Maven 项目的主要区别在于您可以将项目作为 Maven->"Existing Maven Projects" 导入，因此只需要.project在 git 中共享 pom.xml 和文件。Eclipse 然后.classpath, .settings/会自动为您创建文件。因此，显然您不需要共享它们。如果 pom.xml 中的某些内容发生变化，您只需运行 Maven->"Update project configuration" 和 Maven->"Update dependencies"。

Without Maven

没有 Maven

You shouldshare the .projectfile and not the .settings/folder. You can considere to share .classpath but it may lead to conflicts as explained above. I would suggest not to share it either. Use the method below to import the project:

您应该共享.project文件而不是.settings/文件夹。您可以考虑共享 .classpath 但它可能会导致如上所述的冲突。我也建议不要分享。使用以下方法导入项目：

After you have cloned the git repository you can simply use Import->"Existing Project from Workspace" eclipse will honor the .projectfile but recreates the .classpathand .settings/files. After the import you will need to configure the classpath by hand from Eclipse (and everytime your team wants to use another library).

克隆 git 存储库后，您可以简单地使用 Import->"Existing Project from Workspace" eclipse 将尊重该.project文件但重新创建.classpathand.settings/文件。导入后，您需要从 Eclipse 手动配置类路径（并且每次您的团队想要使用另一个库时）。

If you do not share the .project file, then it is not possible to import the project with Eclipse. You will need to create a new project with the project wizard first, and then you can choose import "General->File System", this will copy all the files into your workspace. This is probably not what you want, because it means that you cannot clone the git repository into the workspace, you must clone it somewhere else and then import it from there. Therefore you should always share the .project file.

如果不共享 .project 文件，则无法使用 Eclipse 导入项目。您需要先使用项目向导创建一个新项目，然后您可以选择导入“General->File System”，这会将所有文件复制到您的工作区中。这可能不是您想要的，因为这意味着您无法将 git 存储库克隆到工作区中，您必须将其克隆到其他地方，然后从那里导入。因此，您应该始终共享 .project 文件。

Please leave a commend if you have suggestions to this explanation or if you dont agree with it. I hope this helps the one or other.

如果您对此解释有任何建议或不同意，请留下您的表扬。我希望这对他们有帮助。