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

如果你是在一个团队中工作，那么我认为以下是非常适合进行版本控制的:

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

CDT配置文件不是源代码控制友好的，这是毫无价值的。有一个关于.cproject文件频繁更改并导致冲突的错误文件，请参阅在存储库中共享cdt-project文件总是会导致冲突。

考虑:

.classpath
.project
.launch

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

您可能也想在版本控制中包含.metadata，这样Eclipse开发人员就可以检查整个工作空间，并将其预配置为所有正确的项目，但是它包含了大量特定于用户的信息，任何人在任何时候使用它都会发生变化，因此我建议不要包含.metadata。只需导入所有现有Eclipse项目，就可以轻松构建本地工作区。

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

唯一的例外是.launch XML文件(启动器定义)。

它们存在于

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

它们应该复制到你的项目目录中:当你的项目刷新时，这些配置将显示在“Run configuration”对话框中。

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

(警告:请取消选中Run/Launching/Launch Configuration首选项面板中的“删除关联资源时删除配置”选项:为了重新导入项目，通常会软删除项目—强制重新初始化eclipse元数据。但这个选项，如果勾选，将删除您的详细发射参数!)

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

应该在您的SCM中(特别是根据Eclipse文档的.project和.classpath)。

目标是任何人都可以签出/更新他/她的SCM工作空间，并将Eclipse项目导入Eclipse工作空间。

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

注意:如果project-dir指的是“外部”项目目录，而不是在eclipse工作空间下创建的目录，效果会更好。这样，这两个概念(eclipse工作空间和SCM工作空间)就被清晰地分开了。

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

(摘自博客文章《Tip:从KD创建和分享发射配置》)

我觉得一个都没有。它们很可能包含只与您的工作站相关的信息(我在考虑库和所有的路径)。另外，如果团队中有人不使用Eclipse怎么办?

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

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

我不建议将它们保留在源代码控制中。