哪些 Eclipse 文件属于版本控制？

Which Eclipse files belong under version control?

提问by sblundy

Which Eclipse files is it appropriate to put under source control, aside from the sources obviously?

除了源代码之外，哪些 Eclipse 文件适合置于源代码控制之下？

In my project, specifically, I'm wondering about:

在我的项目中，特别是，我想知道：

.metadata/*
project-dir/.project
project-dir/.classpath
project-dir/.settings/*

.metadata/*
project-dir/.project
project-dir/.classpath
project-dir/.settings/*

If there are any of these for which it depends, please explain your guidelines.

如果有任何依赖，请解释您的指导方针。

采纳答案by VonC

Metadata should not be managed in source control. They contain mostly data relevant to yourworkspace.

元数据不应在源代码管理中进行管理。它们主要包含与您的工作区相关的数据。

The only exception is the .launchXML files (launcher definition).

唯一的例外是.launchXML 文件（启动器定义）。

They are found in

他们被发现在

[eclipse-workspace]\.metadata\.plugins\org.eclipse.debug.core\.launches

And they should be copied into your project directory: When your project is refreshed, those configurations will be displayed in the "Run configuration" dialog.

并且应该将它们复制到您的项目目录中：刷新您的项目后，这些配置将显示在“运行配置”对话框中。

That way, those launch parameter files can be also managed into the SCM.

这样，这些启动参数文件也可以管理到 SCM 中。

(Warning: Do uncheck the option "Delete configurations when associated resource is deleted"in the Run/Launching/Launch Configurationpreference panel: It is common to soft-delete a project in order to import it back again - to force a reinitialization of the eclipse metadata. But this option, if checked, will remove your detailed launch parameters!)

（警告：取消对“当相关资源被删除删除配置”中运行/启动/启动配置偏好面板：这是常见的软删除项目，以导入回来-给力的重新初始化eclipse 元数据。但是如果选中此选项，将删除您的详细启动参数！）

project-dir/.project
project-dir/.classpath
project-dir/.settings/* 

should be in your SCM (especially .projectand .classpathaccording to the Eclipse documentation).

应该在你的供应链管理（尤其是.project和.classpath根据Eclipse文档）。

The goal is that anyone can checkout/update his/her SCM workspace and import the Eclipse project into the Eclipse workspace.

目标是任何人都可以检出/更新他/她的 SCM 工作区并将 Eclipse 项目导入到 Eclipse 工作区。

For that, you want to use only relative pathsin your .classpath, using linked resources.

为此，您只想使用.classpath 中的相对路径，使用链接资源。

Note: it is better if project-dirrefers to an "external" project directory, not a directory created under the eclipse workspace. That way, the two notions (eclipse workspace vs. SCM workspace) are clearly separated.

注意：最好是project-dir指“外部”项目目录，而不是在 eclipse 工作区下创建的目录。这样，这两个概念（eclipse 工作区与 SCM 工作区）就明显分开了。

---

---

As ipsquigglementions in the comment, and as I have alluded to in an old answer, you can actually save the launching configuration as shared filedirectly in your project directory. All launching configuration can then be versioned like the other project files.

正如ipsquiggle在评论中提到的，以及我在旧答案中提到的，您实际上可以将启动配置直接保存为项目目录中的共享文件。然后可以像其他项目文件一样对所有启动配置进行版本控制。

(From the blog post Tip: Creating and Sharing Launch Configurationsfrom KD)

（来自博客文章提示：从 KD创建和共享启动配置）

回答by pdemarest

I am currently working on a project where we have the .project and .cproject files under source control. The idea was that settings related to library paths and link directives would propagate across the team.

我目前正在开发一个项目，我们在源代码控制下拥有 .project 和 .cproject 文件。这个想法是与库路径和链接指令相关的设置将在整个团队中传播。

In practice it hasn't worked very well, merges almost always come back in a conflicted state which need to be deconflicted outside of eclipse and then the project closed and reopened for the changes to take effect.

在实践中它并没有很好地工作，合并几乎总是以冲突状态返回，需要在 eclipse 之外解除冲突，然后项目关闭并重新打开以使更改生效。

I wouldn't recommend keeping them in source control.

我不建议将它们保留在源代码管理中。

回答by Diaa Sami

It's worth nothing that CDTconfiguration files are not source-control-friendly. There's a bug filed for .cproject files changing very frequently and causing conflicts, see Sharing cdt-project files in repository always causes conflicts.

这是值得什么，CDT配置文件不是源代码控制友好。为 .cproject 文件提交了一个错误，它经常更改并导致冲突，请参阅在存储库中共享 cdt-project 文件总是导致冲突。

回答by John Stoneham

Some projects, like those using Maven, like to generate the .project files based on POMs.

一些项目，比如那些使用 Maven 的项目，喜欢基于 POM 生成 .project 文件。

That said, other than that - .metadata should NOT be in source control. Your project will have to make a determination about whether projectdir/.settings does, based on how you plan to manage standards and such. If you can honestly trust your developers to set up their environment based on the standard, and you don't have to customize anything special for any project, then you don't need to put them in. Me, I recommend configuring every project specifically. This allows devs to work on multiple projects' stuff in the same workspace without having to change default settings back and forth, and it makes the settings very explicit, overriding whatever their default settings are to match the project's standards.

也就是说，除此之外 - .metadata 不应该在源代码管理中。您的项目必须根据您计划如何管理标准等来确定 projectdir/.settings 是否有效。如果你能诚实地信任你的开发人员根据标准设置他们的环境，并且你不必为任何项目定制任何特殊的东西，那么你不需要把它们放进去。 我，我建议每个项目都专门配置. 这允许开发人员在同一个工作区中处理多个项目的内容，而不必来回更改默认设置，并且它使设置非常明确，覆盖任何默认设置以匹配项目标准。

Only difficult part is making sure they all stay in sync. But in most cases you can copy the .settings files from project to project. If there are any you specifically don't want in source control, do the equivalent of setting svn:ignore for them, if your SCM supports it.

唯一困难的部分是确保它们都保持同步。但在大多数情况下，您可以将 .settings 文件从项目复制到项目。如果您在源代码管理中特别不想要任何内容​​，请为它们设置 svn:ignore 的等效项（如果您的 SCM 支持）。

回答by Stijn de Witt

The .classpath file is definitively a good candidate for checking into scm as setting it by hand can be a lot of work and will be difficult for new devs getting into the project. It is true it can be generated from other sources, in which case you would check in the other source.

.classpath 文件绝对是签入 scm 的一个很好的候选者，因为手动设置它可能需要很多工作，并且对于新开发人员进入该项目来说将是困难的。的确，它可以从其他来源生成，在这种情况下，您将签入其他来源。

As for .settings, it depends on the settings. This is a grey area, but some settings are almost mandatory and it is convenient to be able to check out a project, import it in Eclipse and have everything set up and good to go.

至于 .settings，这取决于设置。这是一个灰色区域，但有些设置几乎是强制性的，这样可以方便地检出项目、将其导入 Eclipse 并设置好所有内容，一切顺利。

At our project, we therefore maintain a copy of the .settings folder called CVS.settings and we have an ant task to copy it to .settings. When you get the project from CVS, you call the 'eclipsify' ant task to copy the default settings to the new .settings folder. When you configure settings that are needed by everyone developing on the project, you merge those back into the CVS.settings folder and commit that to CVS. This way saving settings in SCM becomes a conscious process. It does require devs to merge those settings back into their .settings folders from time to time when big changes are checked in. But it's a simple system that works surprisingly well.

因此，在我们的项目中，我们维护了一个名为 CVS.settings 的 .settings 文件夹的副本，并且我们有一个 ant 任务将其复制到 .settings。当您从 CVS 获取项目时，您调用 'eclipsify' ant 任务将默认设置复制到新的 .settings 文件夹中。当您配置项目开发人员所需的设置时，您将这些设置合并回 CVS.settings 文件夹并将其提交给 CVS。通过这种方式在 SCM 中保存设置成为一个有意识的过程。它确实需要开发人员在签入重大更改时不时将这些设置合并回他们的 .settings 文件夹。但它是一个简单的系统，运行得非常好。

回答by agnul

I'd say none of them. They most likely contain information that is relevant only to your workstation (I'm thinking about paths for libraries and all). Also what if someone in your team is not using Eclipse?

我会说他们一个都没有。它们很可能包含仅与您的工作站相关的信息（我正在考虑库和所有路径的路径）。另外，如果您团队中的某个人没有使用 Eclipse，该怎么办？

回答by Alex McCarrier

Consider:

考虑：

.classpath
.project
.launch

These SHOULD be in version control as long as you stick to using project-relative paths. This allows other developers to check out the project and start working right away without having to go through all the setup pain that other developers went through as well.

只要您坚持使用与项目相关的路径，这些就应该在版本控制中。这允许其他开发人员检查项目并立即开始工作，而不必经历其他开发人员也经历的所有设置痛苦。

You might be tempted to include .metadata in version control as well so Eclipse developers can check out an entire workspace and have it preconfigured with all the right projects, but it includes a lot of user specific information that anytime anybody works on it, it will change, so I would advise to NOT INCLUDE .metadata. It's easy to build a local workspace just by importing all existing Eclipse projects.

您可能还想在版本控制中包含 .metadata 以便 Eclipse 开发人员可以检查整个工作区并使用所有正确的项目对其进行预配置，但它包含许多特定于用户的信息，任何人在任何时候都可以使用它更改，所以我建议不要包含 .metadata。只需导入所有现有 Eclipse 项目，即可轻松构建本地工作区。

回答by Reto H?hener

I have spent too many hours configuring eclipse workspace settings for new colleagues (and myself). What I ended up doing eventually was copying my own .metadata to the new developer machine.

我花了太多时间为新同事（和我自己）配置 eclipse 工作区设置。我最终做的最终是将我自己的 .metadata 复制到新的开发人员机器上。

If you are working on a team, then I think the following are very good candidates to keep under version control:

如果您在团队中工作，那么我认为以下是保持版本控制的非常好的候选人：

• Installed JREs and their names
• Server Runtime Environments
• Java Editor Templates
• Version Control Keyboard Shortcuts
• Plugin settings that do not provide project specific settings
• Maven settings
• Preconfigured Perspectives
• ...

• 已安装的 JRE 及其名称
• 服务器运行时环境
• Java 编辑器模板
• 版本控制键盘快捷键
• 不提供项目特定设置的插件设置
• Maven 设置
• 预先配置的视角
• ...