我是否应该将项目文件(例如Eclipse的.project，.classpath，.settings)置于版本控制下(例如Subversion，GitHub，CVS，Mercurial等)？

解决方案

这些项目文件似乎可以随着我们在项目上的工作而随时间变化，是的，我将它们置于版本控制之下。

是的，除了.settings文件夹。提交其他文件对我们来说效果很好。这里有一个类似的问题。

.project和.classpath文件是。但是，我们不会将IDE设置保留在版本控制中。有些插件不能很好地保持设置的持久性，我们发现某些设置从一台开发机到另一台开发机的移植性不是很好。因此，我们有一个Wiki页面，突出显示了开发人员设置其IDE所需的步骤。

这些是我认为是生成的文件，因此，我从未将它们置于版本控制之下。它们因机器而异，因开发商而异，例如，当人们安装了不同的Eclipse插件时。

取而代之的是，我使用了一个生成工具(Maven)，当我们进行新签出时，该工具可以生成这些文件的初始版本。

不，我是Maven的重度用户，使用Q for Eclipse插件来创建并保持.project和.classpath的更新。对于其他事情，例如插件设置，我通常会保留一个自述文件或者Wiki页。

同样，我与之合作的人更喜欢其他IDE，只是使用Maven插件来生成保持其IDE(以及他们自己)满意所需的文件。

不可以，因为我只需要构建软件所需的版本控制文件。此外，个别开发人员可能具有自己的项目特定设置。

我想这是所有意见，但多年来的最佳实践表明，除非给整个组织在一个IDE上进行标准化并且我们从未打算进行切换，否则不应将特定于给定IDE的文件存储在源代码控制中。

无论哪种方式，我们都绝对不希望存储用户设置，并且.project可以包含真正针对开发人员的设置。

我建议使用Maven或者Ant之类的东西作为标准化的构建系统。任何开发人员都可以在几秒钟内在其IDE中获得配置的类路径。

我们确实想保留所有可移植设置文件的版本控制，
意义：
任何没有绝对路径的文件。
包括了：

• 。项目，
• .classpath(如果未使用绝对路径，则可以使用IDE变量或者用户环境变量来实现)
• IDE设置(这是我强烈不同意"已接受"答案的地方)。这些设置通常包括静态代码分析规则，这对于对于将这个项目加载到他/她的工作区的任何用户一致地实施至关重要。
• IDE特定的设置建议必须写在一个较大的README文件中(当然，还要进行版本控制)。

我的经验法则：
我们必须能够将项目加载到工作区中，并拥有在IDE中正确设置项目并在几分钟内进行所需的一切。
无需其他文档，无需阅读Wiki页面。
加载，设置，开始。

我在这里有两个选择。

一方面，我认为，只要所有源工件都存储在版本控制中，并且构建脚本(例如ANT或者Maven)可以通过以下方式确保标准合规性，那么每个人都应该可以自由使用他们最高效的开发工具集。确切指定要使用的JDK，要依赖的第三方库的版本，运行样式检查(例如checkstyle)和运行单元测试等。

另一方面，我认为有很多人使用相同的工具(例如Eclipse)，通常在设计时标准化一些东西而不是在构建时进行标准化会好得多，例如Checkstyle作为Eclipse插件比作为一个Eclipse插件有用得多。 ANT或者Maven任务最好是在一组开发工具和一组通用插件上进行标准化。

我在一个项目中工作，每个人都使用完全相同的JDK，相同版本的Maven，相同版本的Eclipse，相同集合的Eclipse插件和相同的配置文件(例如Checkstyle配置文件，代码格式化程序规则等)。所有这些都保存在源代码控制.project，.classpath和.settings文件夹中。当人们不断调整依赖关系或者构建过程时，它使项目的初始阶段的生活变得非常轻松。在向项目添加新的启动器时，它也提供了极大的帮助。

总的来说，我认为如果发生宗教战争的机会不多，则应该标准化基本的开发工具和插件集，并确保构建脚本中的版本符合性(例如，通过明确指定Java版本)。不要认为将JDK和Eclipse安装存储在源代码控制中并没有太大好处。不是衍生工件的所有其他东西，包括项目文件，配置和插件首选项(尤其是代码格式化程序和样式规则)，都应进入源代码控制。

P.S.如果使用Maven，则有一个说法是.project和.classpath文件是派生的工件。仅当我们每次执行构建时都生成它们，并且从未从POM生成它们后不必手动调整它们(或者通过更改某些首选项无意更改它们)时，这才是正确的

是的。除了构建输出外，所有内容都没有。

我们使用IntelliJ IDEA，并在项目控制下将项目(.ipr)和模块(.iml)文件的" .sample"版本保留下来。

恕我直言，这里比共享版本控制更大的事情是共享和重用。但是，如果我们要共享这些配置，那么将它们放置在存储库中比其他所有存储库都合适的地方。

共享和版本化的项目文件的一些优点：

• 我们可以签出任何标签/分支并快速开始处理
• 使新开发人员更容易先设置开发环境并加快开发速度
• 这更好地遵循了DRY，DRY始终令人深切满意。在此之前，所有开发人员都必须不时地设置这些内容，实际上是在做重复的工作。当然，每个人都有自己避免自己重复的小方法，但是从团队整体的角度来看，有很多重复的工作。

请注意，在IDEA中，这些文件包含以下配置："源"和"测试源"目录是什么？有关外部依赖项的所有信息(库jar位于何处以及相关的源代码或者javadocs)；构建选项等。这在开发人员之间并没有什么不同(我非常不同意这一点)。 IDEA将其他个人IDE设置以及其他插件配置存储在其他位置。 (我不太了解Eclipse；这可能会或者可能不会完全不同。)

我同意以下回答：

You must be able to load a project
  into a workspace and have in it
  everything you need to properly set it
  up in your IDE and get going in
  minutes. 
  [...] 
  Load it up, set it up, go.

多亏了版本化的项目文件，我们才有了它。

尽管我通常都同意"不对生成的文件进行版本控制"方法，但是我们对此有问题，必须重新切换。

Note: I am also interested in VonC's answer, particularly about the "get Eclipse up within minutes" point. But it is not decisive to us.

我们的上下文是使用m2eclipse插件的Eclipse + Maven。我们有一个通用的开发环境，并带有尽可能多的通用目录。但是有时候有时候有人会尝试使用插件，或者在配置中进行一些小改动，或者为另一个分支导入另一个工作区...

我们的问题是，在Eclipse中导入项目时，.project的生成已完成，但以后并未在所有情况下都进行更新。令人遗憾的是，随着m2eclipse插件的改进，它可能不是永久的，但现在确实如此。因此，我们最终得到了不同的配置。我们今天所拥有的是：在某些机器上的许多项目中添加了几种性质，然后它们的行为就大不相同了：-(

我们看到的唯一解决方案是对.project文件进行版本控制(为避免风险，我们将对.classpath和.settings执行相同的操作)。这样，当一个开发人员更改pom时，将使用m2eclipse更新本地文件，将所有本地文件一起提交，其他开发人员将看到所有更改。

Note : in our case, we use relative file names, so we have no problem to share those files.

因此，为回答问题，我说是，提交这些文件。

我也喜欢：

• 富裕卖家的答案