文件.settings/org.eclipse.jdt.core.prefs是项目的一部分还是我的个人Eclipse配置的一部分？

我应该把它添加到版本控制中吗？

是的，你应该。如果此文件不受版本控制，则无法创建同一项目的可复制版本，因为它不再是独立的，而是取决于特定的Eclipse安装及其设置。

如果将此项目导入到另一个工作区(在您或任何其他计算机上)，它的行为可能会完全不同，因为编译器符合性设置、编译器警告配置和许多其他内容突然丢失或不同。这样一个项目在新的工作区中突然显示警告/错误的可能性很高，而以前它是完全正常的。

注意：这也要求您在项目属性中实际配置所有与Java相关的设置。如果希望拥有自包含的项目，则不要在Window >首选项下使用Java编译器设置。

给出一个具体的例子：如果您已经将您的项目编译器遵从级别配置为Java 6，因为您正在使用Java 6的特定特性(例如，在接口上重写注释)，那么该项目将在其他人机器上创建大量编译错误。这是因为在每个Eclipse工作区中默认编译器遵从级别是Java 1.5，而在Java 1.5中忽略注释是不允许的。

如另一个答案所示，这与您开发的是封闭源代码还是开放源代码没有任何关系。

与@nitid的观点相反，不应该。您不应该将任何特定于IDE的设置置于版本控制之下。除了开发IDE功能或插件。

如果您真的有强制的团队范围的IDE设置，将它们置于版本控制下是一个好主意，但是IMO拥有强制的团队范围设置本身并不是一个好主意。

对于所有其他情况，共享的IDE设置对于可移植的构建都是有害的，即使使用同一个IDE，对其他IDE的用户来说也是无用的。

编辑：我应该根据项目的目标群体来区分。如果您正在一个与Eclipse一起工作的团队中开发一个封闭源代码产品，那么将这些首选项保持在版本控制之下是一个很有帮助的好主意。如果您正在开发一个库、封闭源代码、开放源代码或开放源代码项目，我会考虑忽略更合适和礼貌的首选项。

伊迪丝2：恐怕@bananenweizen误解了我想说的话。

我知道这些设置是Eclipse编译器设置。它们仍然是特定于IDE的，因为它们在netbeans或intellij中不会有任何影响，因为它们不会对来自命令行的Ant或Maven构建产生任何影响。

是的，将这些设置置于版本控制之外，可以在另一台机器上的Eclipse中为您带来许多红色波浪线。如果它是一个maven项目，顺便说一句，它有一个固定的源代码级别，我不确定Ant。

Eclipse不是自己构建项目——如果是Eclipse或Ant项目，则使用Ant构建项目；如果是Maven项目，则使用Maven构建项目。Ant和Maven都为不依赖于IDES的源版本提供了特定的设置。

这些设置应该在构建文件中。构建文件应该在源代码管理下。我之前提到的例外情况仍然适用。

这是将其置于版本控制之下的问题….如果您导入并打开一个项目，Eclipse坚持当iproject.open(…)在触摸.settings文件夹中的文件时被调用…这是在您可以在IProject对象上注册团队提供者之前完成的。这意味着无论您是单击弹出窗口上的"是"还是"否"，ValidateEdit都不会触发，并且您都会遇到恼人的错误，询问"是否要使其可写？"对于乐观的文件锁定提供者来说，这一切都很好，但对于"悲观的"提供者来说，这并不是什么好事情。对我们来说，这只是另一个日食烦恼。

如果由我来决定，我不可能把它们放在源代码管理中。

答案是"是的"，在这里你可以找到实现它的动机和正确的方法：观看"提交IDE元文件：误解、误解和解决方案"的演讲，或者看看Aur_lien pupier@apupier(Eclipse专家高级软件工程师)在EclipseCon Europe 2015上的相应幻灯片。