我应该将我的项目文件保留在版本控制下吗？

Question

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

Answer 1

您确实希望保留版本控制任何便携式设置文件，
意思是：
任何没有绝对路径的文件。
这包括：

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

我的经验法则：
您必须能够将项目加载到工作区中，并在其中包含在IDE中正确设置项目所需的一切，并在几分钟内完成。 没有其他文档，维基页面可供阅读或不可阅读 加载，设置，去。

Answer 2

.project和.classpath文件是的。但是，我们不会将IDE设置保留在版本控制中。有一些插件不能很好地保持设置，我们发现一些设置从一台开发机器到下一台机器都不是很便携。因此，我们改为有一个Wiki页面，突出显示开发人员设置IDE所需的步骤。

Answer 3

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

相反，我使用构建工具（Maven），当您进行新的结帐时，它可以生成这些文件的初始版本。

Answer 4

我在两个选项之间徘徊。

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

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

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

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

P.S。如果您使用Maven，则有一个参数说明.project和.classpath文件是派生工件。只有在每次构建时都生成它们，并且从POM生成它们之后，您从未必须手动调整它们（或者通过更改某些首选项而无意中更改它们），这是正确的

Answer 5

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

Answer 6

不，我是一个沉重的Maven用户并使用创建的Q for Eclipse插件并更新.project和.classpath。对于插件设置等其他内容，我通常会在README或Wiki页面上保留相关内容。

此外我喜欢其他IDE的人只是使用Maven插件来生成保持IDE（和他们自己）满意所需的文件。

Answer 7

我认为这是所有意见 - 但多年来的最佳实践表明特定于给定IDE的文件不应存储在源代码管理中，除非您的整个组织在一个IDE上标准化且您从未有任何意图切换。

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

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

Answer 8

是的，除了.settings文件夹。提交其他文件对我们很有用。还有一个类似的问题here。

Answer 9

虽然我普遍同意“不要生成版本文件”的方法，但我们遇到了问题并且必须切换回来。

  

注意：我也对VonC's answer感兴趣，特别是关于“在几分钟内获得Eclipse”的观点。但这对我们来说不是决定性的。

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

我们的问题是.project的生成是在Eclipse中导入项目时完成的，但在以后的所有情况下都没有更新。这很悲伤，可能不是永久性的，因为m2eclipse插件会有所改进，但现在也是如此。所以我们最终得到了不同的配置。我们今天所拥有的是：在一些机器上的许多项目中添加了几个性质，然后表现得差异很大： - （

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

  

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

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

---

我也很喜欢：

• Rich Seller的answer

Answer 10

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

Answer 11

是。所有东西，但建立输出。

Answer 12

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

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

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

• 您可以查看任何标记/分支并快速开始处理
• 让新开发人员更容易首先设置开发环境并加快速度
• 这更好地坚持DRY，这总是让人非常满意。在此之前，所有开发人员不得不时不时地设置这些东西，基本上是重复工作。当然，每个人都有自己的小方法来避免重复自己，但是从整体上看整个团队，有很多重复的努力。

请注意，在IDEA中，这些文件包含以下配置：什么是“源”和“测试源”目录;关于外部依赖关系的所有内容（库放置在哪里，以及相关的源或javadoc）;构建选项等。这是不从开发人员到开发人员不同的东西（我强烈反对this）。 IDEA在其他地方存储更多个人IDE设置，以及任何插件配置。 （我不太了解Eclipse;这可能会或可能不会完全不同。）

我同意this answer说：

  

您必须能够加载项目   进入工作区并拥有它   正确设置它所需的一切   在你的IDE中进入   分钟。   [...]   加载，设置，去。

由于版本化的项目文件，我们就是这样的。