我应该保留项目文件,如Eclipse的.project,.classpath,.settings,在版本控制下(例如Subversion,GitHub,CVS,Mercurial等)？
您确实希望在版本控制中保留任何可移植设置文件,
这意味着:
任何没有绝对路径的文件.
那包括:
.项目,
.classpath(如果没有使用绝对路径,可以使用IDE变量或用户环境变量)
IDE设置(我不同意'接受'的答案).这些设置通常包括静态代码分析规则,这对于将此项目加载到他/她的工作区中的任何用户始终如一地执行至关重要.
IDE特定的设置建议必须写在一个大的README文件中(当然也是版本化的).
我的经验法则:
您必须能够将项目加载到工作区中,并在其中包含在IDE中正确设置它所需的一切,并在几分钟内完成.
没有其他文档,维基页面可读或不可读.
加载,设置,去.
.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版本).I不要认为将JDK和Eclipse安装存储在源代码管理中有很多好处.其他不是派生工件的东西 - 包括你的项目文件,配置和插件首选项(特别是代码格式化程序和样式规则) - 应该进入源代码控制.
PS如果您使用Maven,则有一个论据可以说.project和.classpath文件是派生工件.只有在每次进行构建时生成它们,并且从POM生成它们之后从未必须手动调整它们(或通过更改某些首选项而无意中更改它们)时,才会出现这种情况.
不,因为我只是构建软件所需的版本控制文件.此外,个别开发人员可能拥有自己的项目特定设置.
不,我是一个沉重的Maven用户,并使用Q for Eclipse插件创建并保持.project和.classpath更新.对于其他内容,例如插件的设置,我通常会保留一个README或Wiki页面.
还有那些我喜欢其他IDE的人只是使用Maven插件来生成保持IDE(和他们自己)快乐所需的文件.
我认为这是所有观点 - 但多年来的最佳实践表明,特定于给定IDE的文件不应存储在源代码控制中,除非您的整个组织在一个IDE上标准化,并且您从未有任何转换意图.
无论哪种方式,您绝对不希望存储用户设置 - 而.project可以包含真正特定于开发人员的设置.
我建议使用像Maven或Ant这样的标准化构建系统.任何开发人员都可以在几秒钟内在IDE中配置类路径.
京公网安备 11010802040832号 | 京ICP备19059560号-6 