当前位置：文江博客话题详情

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

发布于 2024-10-04 14:11:27 字数 277 浏览 8 评论 0原文

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

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

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

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

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

和我恋爱吧 2024-10-11 14:11:27

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

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

（如果他们应该了解其他文件规范，请让他们知道！）

回复收藏 0 原文

紧拥背影 2024-10-11 14:11:27

元数据和工作区

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

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

特定于项目

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

.settings "http://help.eclipse.org/indigo/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/misc/project_description_file.html" rel="noreferrer">eclipse 文档有关 .project 文件的说明如下：

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

和：

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

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

Maven

的问题。与 Maven 项目的主要区别在于您可以将项目导入为 Maven->”现有的 Maven 项目”，因此只需要在 git 中共享 pom.xml 和 .project 文件。然后 Eclipse 将自动为您创建 .classpath、.settings/ 文件。因此显然你不需要分享它们。如果 pom.xml 中发生某些变化，您只需运行 Maven->“更新项目配置”和 Maven->“更新依赖项”。

没有 Maven

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

克隆 git 存储库后，您可以简单地使用导入->“工作空间中的现有项目”，eclipse 将遵循 .project 文件，但重新创建 .classpath 和 .settings/ 文件。导入后，您需要从 Eclipse 手动配置类路径（每次您的团队想要使用另一个库时）。

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

如果您对此解释有建议或不同意，请留言。我希望这对其中一方或另一方有所帮助。

Metadata and Workspace

I would never share the .metadata folder. 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 .metadata folder 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:

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

Project Specific

You should probably always share the .project file and never .settings/ files. The .classpath may 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 .settings contains 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.

The eclipse documentation states the following about the .project file:

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

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 .project file 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".

Without Maven

You should share the .project file 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:

After you have cloned the git repository you can simply use Import->"Existing Project from Workspace" eclipse will honor the .project file but recreates the .classpath and .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).

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.

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.

回复收藏 0 原文