是否应将项目文件置于版本控制下？[关闭]

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

您确实希望保持任何可移植设置文件的版本控制，
这意味着：
其中没有绝对路径的任何文件。
那包括：

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

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

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

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

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

我在这里有两个选择。

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

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

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

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

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

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

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

同样，我与那些喜欢其他IDE的人只是使用Maven插件来生成保持其IDE（以及他们自己）满意所需的文件。

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

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

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

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

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

注意：我对VonC的答案也很感兴趣，特别是关于“在几分钟之内建立Eclipse”这一点。但这对我们不是决定性的。

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

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

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

注意：在本例中，我们使用相对文件名，因此共享这些文件没有问题。

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

我也喜欢：

• 富卖方的答案

这些项目文件在您处理项目时似乎会随着时间而变化，因此，是的，我将其置于版本控制下。

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

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

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

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

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

请注意，在IDEA中，这些文件包含以下配置：“源”和“测试源”目录是什么？有关外部依赖项的所有信息（库jar以及相关源或javadocs的位置）；编译选项等，这是东西，它不是从开发到开发者（我不同意改变此相当强烈）。IDEA将更多的个人IDE设置以及其他插件配置存储在其他位置。（我不太了解Eclipse；这可能会或可能不会完全不同。）

我同意以下回答：

您必须能够将项目加载到工作区中，并拥有在IDE中正确设置项目并在几分钟内开始所需的一切。[...]加载，设置，开始。

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