我还没有尝试过将.metadata中的任何东西置于版本控制之下，但我对这些文件使用版本控制已经有十年了:

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

主要原因是Eclipse有时会损坏这些文件。如果没有版本控制，您就会变得很奇怪，并且很难跟踪错误。使用版本控制，您可以立即看到“为什么它试图部署测试类??”或“为什么Maven和Eclipse使用相同的类路径?”(通往https://bugs.eclipse.org/bugs/show_bug.cgi?id=430605)。

使用版本控制，您可以看到它何时发生，并轻松地返回到配置文件的工作集。

如果您使用m2e:您现在可以使用快速的“import existing project”导入项目，而不是缓慢的“import Maven project”。

这种方法的缺点是Eclipse似乎会随机更改其中一些文件。大多数插件保持它们的稳定，但有些使用HashMap而不是LinkedHashMap，所以元素的顺序一直在变化。这意味着提交时有一个额外的步骤:首先检查所有修改过的设置并处理它们。

这也意味着整个团队必须在一些标准上达成一致:比如应该启用哪些警告。有趣的是，许多人把这看作是一个额外的问题——就好像他们没有在一起工作一样。

根据我的经验，这些文件稳定下来需要几周时间。部分原因是您逐渐学会了如何调整Eclipse，部分原因是人们学会了哪些东西不能碰。你可以把这看作是浪费的时间，或者是花在改善工作环境质量上的时间(比如保持办公桌整洁)。

“先提交设置”还有一个额外的好处:它让人们更频繁地、更小的提交(也就是说，更像是“一次一个想法”，而不是“一次一个功能加上成千上万其他我碰巧偶然发现的不相关的事情……我在做什么来着?”)。

作为一名经验丰富的开发人员，我更喜欢“小提交”的工作方式;坚持下去更容易，你倾向于把你的想法和改变分成更小、更易于管理的步骤。这有助于降低复杂性。每个人都能玩一个球，没人能玩20个球。

PS:对于某些设置文件，我有单元测试，以确保已知的错误不会像“试图在WTP中部署测试”那样悄悄出现。这有助于在初始阶段“提交所有东西，我太忙了”阶段。

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

唯一的例外是.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创建和分享发射配置》)

考虑:

.classpath
.project
.launch

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

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

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

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

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

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

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