哪些Eclipse文件受版本控制？
Answers:
不应在源代码管理中管理元数据。它们主要包含与您的工作空间相关的数据。
唯一的例外是.launchXML文件（启动程序定义）。
他们在
[eclipse-workspace]\.metadata\.plugins\org.eclipse.debug.core\.launches
然后将它们复制到您的项目目录中：刷新项目时，这些配置将显示在“运行配置”对话框中。
这样，那些启动参数文件也可以管理到SCM中。
（警告：取消对“当相关资源被删除删除配置”中运行 / 启动 / 启动配置偏好面板：这是常见的软删除项目，以导入回来-给力的重新初始化eclipse元数据。但是，如果选中此选项，将删除您的详细启动参数！）
project-dir/.project
project-dir/.classpath
project-dir/.settings/*
应该在你的供应链管理（尤其是.project和.classpath根据Eclipse文档）。
目标是任何人都可以签出/更新其SCM工作区并将Eclipse项目导入Eclipse工作区。
为此，您要使用链接资源仅在.classpath中使用相对路径。
注意：最好project-dir引用“外部”项目目录，而不是在Eclipse工作区下创建的目录。这样，两个概念（Eclipse工作区与SCM工作区）就清晰地分开了。
正如ipsquiggle在评论中提到的那样，正如我在一个旧答案中提到的那样，您实际上可以将启动配置直接保存为共享文件到您的项目目录中。然后，可以像其他项目文件一样对所有启动配置进行版本控制。
.project暂时仅针对您的工作空间忽略该版本。但是不要剥夺所有其他用户可以在其Eclipse工作空间中快速导入的通用Eclipse项目定义，只是因为您碰巧有一个仅满足您当前需要的额外定义。
这是值得什么，CDT配置文件不是源代码控制友好。.cproject文件存在一个错误归档，该错误非常频繁地更改并导致冲突，请参阅在存储库中共享cdt-project文件始终会导致冲突。
某些项目（例如使用Maven的项目）喜欢基于POM生成.project文件。
就是说，除此之外-.metadata不应处于源代码控制中。您的项目必须根据计划如何管理标准等来确定projectdir / .settings是否起作用。如果您可以诚实地相信您的开发人员可以根据标准来设置他们的环境，而不必为任何项目定制任何特殊的东西，那么您就不需要放入它们。我建议您专门配置每个项目。这使开发人员可以在同一工作空间中处理多个项目的内容，而不必来回更改默认设置，并且使设置非常明确，可以覆盖其默认设置以符合项目标准的任何设置。
唯一困难的部分是确保它们都保持同步。但是在大多数情况下，您可以在项目之间复制.settings文件。如果您明确不想在源代码管理中进行任何操作，请在您的SCM支持的情况下，对它们进行相当于设置svn：ignore的操作。
.classpath文件绝对是检查scm的不错选择，因为手动设置它可能需要很多工作，并且对于新开发人员进入该项目将是困难的。确实可以从其他来源生成它，在这种情况下，您需要签入其他来源。
至于.settings，取决于设置。这是一个灰色区域，但是有些设置几乎是必需的，并且能够检出项目，将其导入Eclipse并进行所有设置并方便进行。
因此，在我们的项目中，我们维护一个名为CVS.settings的.settings文件夹的副本，并且我们有一个ant任务将其复制到.settings。从CVS获取项目时，您将调用“ eclipsify” ant任务将默认设置复制到新的.settings文件夹中。当配置项目上所有开发人员都需要的设置时，可以将其合并回CVS.settings文件夹，并将其提交给CVS。这样，将设置保存在SCM中就成为一个有意识的过程。确实需要开发人员在签入重大更改时不时将这些设置重新合并到他们的.settings文件夹中。但这是一个简单的系统，效果非常好。
我什么都不说。它们很可能包含仅与您的工作站相关的信息（我正在考虑库的路径和所有路径）。如果团队中的某人没有使用Eclipse，该怎么办？
考虑：
.classpath
.project
.launch
只要您坚持使用项目相对路径，这些都应该在版本控制中。这使其他开发人员可以检出项目并立即开始工作，而不必经历其他开发人员也经历的所有安装难题。
您可能还会尝试将.metadata包含在版本控制中，因此Eclipse开发人员可以签出整个工作区并使用所有正确的项目对其进行预配置，但是它包含许多用户特定的信息，任何人在任何时候都可以使用它。更改，所以我建议不要包含.metadata。只需导入所有现有的Eclipse项目即可轻松构建本地工作区。
我花了太多时间为新同事（和我自己）配置Eclipse工作区设置。我最终要做的最终是将自己的.metadata复制到新的开发人员计算机上。
如果您在团队中工作，那么我认为以下是保持版本控制的很好的候选人：
- 已安装的JRE及其名称
- 服务器运行时环境
- Java编辑器模板
- 版本控制键盘快捷键
- 不提供项目特定设置的插件设置
- Maven设置
- 预配置的观点
- ...
common选项卡上选择Save as > shared file。这会将其直接放到项目文件夹中，因此可以与项目的其余部分进行SCM处理。