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

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

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

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

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

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

我觉得一个都没有。它们很可能包含只与您的工作站相关的信息(我在考虑库和所有的路径)。另外，如果团队中有人不使用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.

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

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

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

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