有些项目，比如使用Maven的项目，喜欢基于POMs生成.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.

唯一困难的部分是确保它们保持同步。但在大多数情况下，您可以将.settings文件从一个项目复制到另一个项目。如果有任何您特别不想在源代码控制中使用的内容，为它们设置svn:ignore，如果您的SCM支持的话。

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

唯一的例外是.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之外消除冲突，然后项目关闭并重新打开以使更改生效。

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

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

至于.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.

我还没有尝试过将.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中部署测试”那样悄悄出现。这有助于在初始阶段“提交所有东西，我太忙了”阶段。