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

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

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

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

有些项目，比如使用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支持的话。

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.

考虑:

.classpath
.project
.launch

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

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