代码之家  ›  专栏  ›  技术社区  ›  cretzel

我是否应该对项目文件进行版本控制?[闭门]

  •  84
  • cretzel  · 技术社区  · 18 年前

    我是否应该像Eclipse的.project、.classpath、.settings那样保持项目文件处于版本控制之下(例如Subversion、GitHub、CVS、Mercurial等)?

    12 回复  |  直到 10 年前
        1
  •  95
  •   VonC    18 年前

    您确实希望保持版本控制 任何可移植的设置文件
    意思是:
    没有绝对路径的任何文件。
    这包括:

    • 项目
    • .classpath( 如果没有使用绝对路径 ,这在使用IDE变量或用户环境变量时是可能的)
    • IDE设置 (这就是我强烈反对“已接受”答案的原因)。这些设置通常包括 静态代码分析规则 对于任何将此项目加载到其工作区的用户来说,一致地实施这一点至关重要。
    • IDE特定的设置建议必须写在一个大的自述文件中(当然还有版本)。


    您必须能够将项目加载到工作区中,并在其中包含在IDE中正确设置项目所需的所有内容,并在几分钟内开始工作。

    装上,装上,走。

        2
  •  30
  •   Kevin    18 年前

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

        3
  •  18
  •   Chris Vest    18 年前

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

    相反,我使用一个构建工具(Maven),当您进行新的签出时,它可以生成这些文件的初始版本。

        4
  •  7
  •   Vihung    18 年前

    我在两种选择之间左右为难。

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

    我在一个项目中工作,每个人都使用完全相同的JDK、相同版本的Maven、相同版本的Eclipse、相同的Eclipse插件集和相同的配置文件(例如Checkstyle概要文件、代码格式化程序规则等)。所有这些都保存在源代码管理-.project、.classpath和.settings文件夹中的所有内容中。在项目的初始阶段,当人们不断调整依赖项或构建过程时,它使生活变得非常轻松。在为项目增加新的启动者时,它也起到了巨大的作用。

    总的来说,我认为如果没有太多的宗教战争的机会,您应该标准化开发工具和插件的基本集合,并确保构建脚本中的版本符合性(例如,通过明确指定Java版本).我认为在源代码管理中存储JDK和Eclipse安装没有多大好处。非派生工件的所有其他内容——包括项目文件、配置和插件首选项(特别是代码格式化程序和样式规则)——都应该纳入源代码管理。

    另外,如果您使用Maven,则有理由认为.project和.classpath文件是派生工件。只有在每次构建时生成它们,并且在从POM生成它们之后从未手动调整它们(或通过更改某些首选项无意中更改它们),这才是正确的

        5
  •  6
  •   John Topley    18 年前

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

        6
  •  5
  •   Andreas Holstenson    18 年前

    不,我是个笨重的人 Maven 用户和使用 Q for Eclipse

    还有那些我与之共事过的喜欢其他IDE的人,他们只是使用Maven插件来生成使他们的IDE(和他们自己)满意所需的文件。

        7
  •  5
  •   Kevin Day    18 年前

    我想这都是我的看法,但多年来的最佳实践表明,特定于给定IDE的文件不应该存储在源代码管理中,除非您的整个组织在一个IDE上实现了标准化,并且您从未打算切换。

    无论如何,您肯定不希望存储用户设置,并且.project可以包含真正特定于开发人员的设置。

        8
  •  1
  •   Community Mohan Dere    9 年前

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

        9
  •  1
  •   Community Mohan Dere    9 年前

    虽然我大体上同意“不要版本生成文件”的方法,但我们在这方面有问题,必须切换回去。

    注:我也对 VonC's answer ,特别是关于“几分钟内启动Eclipse”这一点。但这对我们来说并不是决定性的。

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

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

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

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


    我还喜欢:

        10
  •  0
  •   neuroguy123    18 年前

        11
  •  0
  •   nitind    17 年前

    对除了构建输出之外,其他一切都可以。

        12
  •  0
  •   Community Mohan Dere    9 年前

    共享和重用

    共享&版本控制的项目文件:

    • 您可以签出任何标记/分支并快速开始处理它
    • 使新开发人员更容易首先设置开发环境并加快开发速度
    • 这更好地坚持干燥,这是始终深刻的满足。在此之前,, 全部的 开发人员必须时不时地设置这些东西,基本上是重复工作。当然,每个人都有自己的小方法来避免重复自己,但是从整个团队来看,有很多重复的努力。

    注意,在IDEA中,这些文件包含如下配置:“源”和“测试源”目录是什么;关于外部依赖关系的一切(库JAR位于何处,以及相关的源或Javadoc);构建选项,等等。这就是 不 不同的开发者不同(我不同意 this

    我同意 this answer

    您必须能够加载项目 进入一个工作区,并在其中 你需要的一切,以正确设置它 分钟 [...]

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