|
1
95
您确实希望保持版本控制
任何可移植的设置文件
|
|
|
2
30
.project和.classpath文件是。但是,我们不会将IDE设置保留在版本控制中。有些插件在持久化设置方面做得不好,我们发现有些设置从一台开发人员机器到下一台开发人员机器的移植性不是很好。因此,我们有一个Wiki页面,它突出显示了开发人员设置IDE所需的步骤。 |
|
|
3
18
这些是我认为生成的文件,因此我从不把它们放在版本控制之下。它们可能因机器和开发人员而异,例如,当人们安装了不同的Eclipse插件时。 相反,我使用一个构建工具(Maven),当您进行新的签出时,它可以生成这些文件的初始版本。 |
|
|
4
7
我在两种选择之间左右为难。
另一方面,我认为很多人使用相同的工具(例如Eclipse)通常,在设计时而不是在构建时对某些东西进行标准化要好得多——例如,Checkstyle作为Eclipse插件比作为ANT或Maven任务有用得多——更好的做法是对开发工具集和通用插件集进行标准化。 我在一个项目中工作,每个人都使用完全相同的JDK、相同版本的Maven、相同版本的Eclipse、相同的Eclipse插件集和相同的配置文件(例如Checkstyle概要文件、代码格式化程序规则等)。所有这些都保存在源代码管理-.project、.classpath和.settings文件夹中的所有内容中。在项目的初始阶段,当人们不断调整依赖项或构建过程时,它使生活变得非常轻松。在为项目增加新的启动者时,它也起到了巨大的作用。 总的来说,我认为如果没有太多的宗教战争的机会,您应该标准化开发工具和插件的基本集合,并确保构建脚本中的版本符合性(例如,通过明确指定Java版本).我认为在源代码管理中存储JDK和Eclipse安装没有多大好处。非派生工件的所有其他内容——包括项目文件、配置和插件首选项(特别是代码格式化程序和样式规则)——都应该纳入源代码管理。 另外,如果您使用Maven,则有理由认为.project和.classpath文件是派生工件。只有在每次构建时生成它们,并且在从POM生成它们之后从未手动调整它们(或通过更改某些首选项无意中更改它们),这才是正确的 |
|
|
5
6
不,因为我只需要构建软件所需的版本控制文件。此外,个别开发人员可能有自己的项目特定设置。 |
|
|
6
5
不,我是个笨重的人 Maven 用户和使用 Q for Eclipse 还有那些我与之共事过的喜欢其他IDE的人,他们只是使用Maven插件来生成使他们的IDE(和他们自己)满意所需的文件。 |
|
|
7
5
我想这都是我的看法,但多年来的最佳实践表明,特定于给定IDE的文件不应该存储在源代码管理中,除非您的整个组织在一个IDE上实现了标准化,并且您从未打算切换。 无论如何,您肯定不希望存储用户设置,并且.project可以包含真正特定于开发人员的设置。
|
|
|
8
1
是,除了.settings文件夹。提交其他文件对我们来说很好。还有一个类似的问题 here . |
|
|
9
1
虽然我大体上同意“不要版本生成文件”的方法,但我们在这方面有问题,必须切换回去。
我们的问题是.project的生成是在Eclipse中导入项目时完成的,但是 以后不会在所有情况下更新 . 这很令人伤心,而且可能不是永久性的,因为m2eclipse插件将有所改进,但现在确实如此。所以我们最终会有不同的配置。我们今天得到的是: 在某台机器上的许多项目中添加了几个性质,这些性质的行为就大不相同了 :-( 我们看到的唯一解决方案是对.project文件进行版本设置 (为了避免风险,我们将对.classpath和.settings执行相同的操作)。这样,当一个开发人员更改pom时,本地文件将使用m2eclipse更新,所有文件都将提交到一起,其他开发人员将看到所有更改。
所以,为了回答你的问题,我说是的,提交那些文件。 我还喜欢:
|
|
|
10
0
|
|
|
11
0
对除了构建输出之外,其他一切都可以。 |
|
|
12
0
共享和重用 共享&版本控制的项目文件:
注意,在IDEA中,这些文件包含如下配置:“源”和“测试源”目录是什么;关于外部依赖关系的一切(库JAR位于何处,以及相关的源或Javadoc);构建选项,等等。这就是 不 不同的开发者不同(我不同意 this 我同意 this answer
多亏了版本化的项目文件,我们才有了这样的版本。 |
|
|
lim-org · 我找不到“配置”的位置 2 年前 |