90

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

4

12 回答 12

96

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

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

我的经验法则：
您必须能够将项目加载到工作区中，并在其中拥有在 IDE 中正确设置并在几分钟内开始运行所需的一切。
没有额外的文档，维基页面阅读或什么没有。
加载它，设置它，去。

于 2008-09-23T06:25:25.423 回答
30

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

于 2008-09-22T17:12:44.707 回答
18

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

相反，我使用了一个构建工具 (Maven)，它可以在您进行新的结帐时生成这些文件的初始版本。

于 2008-09-22T17:13:38.930 回答
7

我在这里的两个选择之间左右为难。

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

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

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

总的来说，我认为如果发生宗教战争的可能性不大，您应该标准化基本的开发工具和插件集，并确保构建脚本中的版本合规性（例如通过明确指定 Java 版本）。I不要认为将 JDK 和 Eclipse 安装存储在源代码管理中有什么好处。其他不是派生工件的东西——包括你的项目文件、配置和插件首选项（特别是代码格式化程序和样式规则）——都应该进入源代码控制。

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

于 2008-09-23T09:56:21.033 回答
6

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

于 2008-09-22T18:27:17.677 回答
5

不，我是一个重度Maven用户，使用Q for Eclipse插件创建并保持 .project 和 .classpath 更新。对于其他的东西，比如插件的设置，我通常会维护一个 README 或 Wiki 页面。

同样，我与之合作过的那些更喜欢其他 IDE 的人只需使用 Maven 插件来生成让他们的 IDE（和他们自己）满意所需的文件。

于 2008-09-22T18:24:40.603 回答
5

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

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

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

于 2008-09-23T04:50:31.097 回答
1

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

于 2008-09-22T17:06:57.153 回答
1

虽然我普遍同意“不版本生成文件”的方法，但我们遇到了问题，不得不切换回去。

注意：我也对VonC 的回答感兴趣，特别是关于“在几分钟内启动 Eclipse”这一点。但这对我们来说不是决定性的。

我们的上下文是Eclipse+Maven，使用m2eclipse插件。我们有一个共同的开发环境，尽可能的有共同的目录。但有时有人会尝试一个插件，或者更改配置中的一些小东西，或者为不同的分支导入第二个工作区......

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

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

注意：在我们的例子中，我们使用相对文件名，所以我们可以共享这些文件。

所以，为了回答你的问题，我说是的，提交这些文件。

我也喜欢：

于 2009-10-28T17:05:32.380 回答
0

似乎这些项目文件在您处理项目时会随着时间而改变，所以是的，我将它们置于版本控制之下。

于 2008-09-22T17:06:31.537 回答
0

是的。除了构建输出之外的所有内容。

于 2008-10-15T06:33:00.840 回答
0

我们使用 IntelliJ IDEA，并将项目 (.ipr) 和模块 (.iml) 文件的“.sample”版本置于版本控制之下。

恕我直言，这里比版本控制更重要的是共享和重用。但是，如果您要共享这些配置，还有什么比存储库更好的放置它们的地方，就在其他所有东西旁边。

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

  • 您可以检查任何标签/分支并快速开始工作
  • 使新开发人员更容易首先设置开发环境并加快速度
  • 这更好地遵守了 DRY，这总是令人深感满足。在此之前，所有开发人员都必须时不时地设置这些东西，基本上是重复工作。当然，每个人都有自己避免重复的小方法，但从团队整体来看，重复的努力很多。

请注意，在 IDEA 中，这些文件包含以下配置：“源”和“测试源”目录是什么；关于外部依赖的一切（库 jars 的位置，以及相关的源代码或 javadocs）；构建选项等。这是因开发人员而异的东西（我非常不同意这一点）。IDEA 在别处存储更多个人 IDE 设置，以及任何插件配置。（我不太了解 Eclipse；这可能会也可能不会完全不同。）

我同意这个答案，说：

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

多亏了版本化的项目文件，我们才有了这样的结果。

于 2009-06-09T13:10:25.903 回答