IntelliJ IDEA 9 + Maven +版本控制的最佳实践

该项目正在使用Maven,因此POM文件是项目信息的主要来源.项目文件中有一些有用的设置,这些设置很好.

OTOH IDEA似乎在项目文件结构中创建了太多冗余更改,这些更改会污染SVN历史记录,有时会产生冲突.

我应该将.idea目录和*.iml文件保留在版本控制下吗？在全？在一部分？

更新:所以我发现为我和我的团队工作的最佳实践是:

签入所有IDEA文件,*.iml和.idea目录.它们包含有价值的信息,每次更新时都会浪费时间重新创建它.

为每个开发人员创建私有分支

进入.idea目录

svn将其切换到其私有分支对应

不要在常规提交中签入IDEA文件 - 它们会污染历史记录.在特殊提交中检查它们.

这样,您可以将.idea目录的内容保留在版本控制中,但不要使其不受常规提交的影响.任何开发人员都可以访问任何其他人的IDEA目录.

更新2:由于这个问题是写的,我已经改变了我的做法,没有将许多IntelliJ文件签入到版本控制中,正如许多响应者所建议的那样.这是我目前对Maven和Gradle的做法.这些工具已发展到可以始终从原始.POM或.gradle文件中重现关键信息.当文件发生更改时,IDE会可靠地跟踪更改,因此您不会丢失通常因此无需检入的IDE文件.

更新3:问这个问题后7年似乎仍然相关.同样的最佳实践也适用于Gradle(也可能是SBT):不要检查IDE文件,根据需要从基本POM,.gradle或SBT文件重新创建它们.

1> Pascal Thive..：

---

简短的回答:不要将这些文件放在源控件存储库中,因为您可以"生成"它们(如果您不需要它们,如果它们很烦人,如果它们可以破坏其他环境,则更是如此).

我个人使用以下值svn:ignore:

target 
*~ 
*.log 
.classpath 
.project 
*.ipr 
*.iws 
*.iml 
.settings 

---

这个答案忽略了在签出/更新后立即拥有iml文件的价值.我已经看到开发人员浪费了大量时间,他们必须弄清楚,他们需要在更新后重新生成iml.将它们放入VC中实际上对其他人很友善.盲目地遵循一般的"不提交生成的东西"规则在这里只会造成伤害.

---

Actualy,IDEA项目(.ipr)和IDEA模块(.iml)文件旨在共享,因此您应该将它们检查到源代码管理中.还有一个不应共享的IDEA Workspace(.iws)文件.

---

除非我离开这里,否则不能简单地重新生成.idea目录中的许多设置.我们讨论的是如何将项目拆分为模块,哪些模块具有哪些方面,需要生成哪些工件,构建过程是什么等等.这是关键信息.现在,如果你可以从其他文件生成所有这些信息,那么考虑走这条路线,但对于这里的问题,我没有看到.

2> sal..：

---

关于Maven的一个好处是,工具支持用于将POM转换为Eclipse,Idea和Netbeans中的本机项目.如果你有一个pom,你可以很快创建一个本机项目.

出于这个原因,我不会检查源代码控制下的.idea或*.iml文件,而不是检查RMI存根或类文件.

---

+1表示在团队中使用多个IDE时的好处

3> alexei.vidmi..：

---

我认为你应该把.idea目录放到版本控制中.其中包含的大多数配置都应该跟踪版本,例如编译器配置.

唯一不属于版本控制的文件是.idea/workspace.xml,因为它只包含特定于本地环境的配置.

IntelliJ Idea实际上默认将workspace.xml放入忽略列表中,因此如果您使用Idea来签入,则应该全部设置而不更改任何内容.

---

Sasha,这就是我所看到的: - 添加或更改库的范围.当团队中有10个人向项目添加库时,我希望其余9个开发人员获得此更新,而不是手动计算出来. - /target/work不再被排除在外.同样的事情,我希望这个改变能够传播. - 编译器设置更改.不确定,它可能是IDEA版本升级或故意更改的工件.

4> mcherm..：

---

我看到标准答案是"不要检查项目文件,只是.pom".但是像.ipr文件这样的东西包含许多无法从.pom文件派生的有用设置.如果IntelliJ用户想要分享这些设置怎么办？我知道.ipr文件被设计为版本化(例如,参见此线程).我希望我有一个实际的答案,但我还没有找到一个好的做法.