logo标签列表

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

intellij-ideagradleversion-controlsbtmaven-2
41
该项目使用Maven，因此POM文件是项目信息的主要来源。项目文件中有一些有用的设置，最好保留。
然而，IDEA似乎在项目文件结构中创建了太多的冗余更改，这污染了SVN历史记录，并有时会导致冲突。
我应该完全保留.idea目录和*.iml文件吗？还是只保留其中一部分？
更新：到目前为止，我和我的团队找到的最佳做法是：
1. 检入所有的IDEA文件，包括*.iml和.idea目录。它们包含有价值的信息，每次更新都重新创建它们是浪费时间的。 2. 为每个开发人员创建私有分支 3. 进入.idea目录 4. 将其切换到相应的私有分支 5. 不要在普通提交中检入IDEA文件--它们会污染历史记录。在特殊提交中检入它们。
这样，你可以将.idea目录的内容保存在版本控制中，但不会影响普通提交。任何开发人员都可以访问其他人的IDEA目录。
更新2：自从写这个问题以来，我已经改变了我的做法，不再将任何IntelliJ文件检入版本控制中，正如许多回答者所建议的那样。这是我目前在Maven和Gradle中使用的做法。这些工具已经发展到了可以从原始的.POM或.gradle文件中始终重建关键信息的程度。当文件更改时，IDE可靠地跟踪更改，因此你不会经常丢失IDE文件，因此没有必要进行检入。
更新3：7年后问这个问题似乎仍然有意义。同样的最佳实践也适用于Gradle（可能也适用于SBT）：不要将IDE文件检入，根据需要从基本的POM、.gradle或SBT文件重新创建它们。
1
感谢大家的建议。与此同时，我的最佳实践是将IDEA文件作为单独的变更集检入，以便不会对SVN历史记录造成太大的影响。我通常会将这些变更集命名为“IDEA疯狂” :-) - Sasha O
1
请参考IDEA FAQ：http://devnet.jetbrains.com/docs/DOC-1186，了解有关IntelliJ IDEA 9/10中应该检入或不检入源代码控制的文件夹。 - Matthew Cornell
@MatthewCornell，也许您可以将您的评论升级为答案？ - Jonas Berlin
6个回答
17

简短回答：不要将这些文件放入源代码控制库中，因为你可以“生成”它们（如果你不需要它们、它们很烦人或者它们可能会破坏其他环境，这就更加正确了）。

我个人使用以下值来设置 svn:ignore：

target 
*~ 
*.log 
.classpath 
.project 
*.ipr 
*.iws 
*.iml 
.settings
5
这个回答忽略了在检出/更新后立即拥有iml文件的价值。我见过许多开发人员浪费时间，他们不得不弄清楚需要在更新后重新生成imls文件。将它们放入VC对其他人很友好。盲目遵循“不提交生成的东西”的一般规则只会在这里造成伤害。 - Przemek Pokrywka
3
除非我理解错了，.idea目录中的许多设置不能简单地重新生成。我们正在谈论如何将项目分割成模块，哪些模块附加了什么特性，需要生成什么工件，构建过程是什么等关键信息。如果您可以从其他文件中生成所有这些信息，请考虑采用该方法，但对于这个问题，我没有看到这一点。 - David J.
1
这在涉及到很多人参与的大型项目中是不可行的。例如，在我们的情况下，我们还会将IDE执行的检查和代码格式样式存储在那里。 - Mikel
4
实际上，IDEA项目（.ipr）和IDEA模块（.iml）文件的设计目的是共享的，因此您应该将它们检入源代码控制。还有一个不应该共享的IDEA工作空间（.iws）文件。 - James Tikalsky
15

Maven的优点之一就是工具支持可将POM转换为Eclipse、Idea和Netbeans中的本机项目。如果您有一个pom，您可以相当快速地创建一个本机项目。

因此，我不会像检入RMI存根或类文件一样检入.idea或*.iml文件到源代码控制中。

2
使用多个 IDE 在团队中的好处是可以提高协作效率，允许每个开发人员使用自己喜欢的工具，并且可以使整个团队更加灵活和适应不同的项目需求。+1 - Nils Schmidt
14

我认为你应该把 .idea 目录放进版本控制中。其中的大部分配置都应该被跟踪，例如编译器配置。

唯一不适合放入版本控制的文件是 .idea/workspace.xml，因为它只包含特定于您本地环境的配置。

实际上，IntelliJ IDEA 默认会将 workspace.xml 添加到忽略列表中，因此如果您使用 IDEA 进行检入，您无需更改任何内容即可完成设置。

Alexei，这是一个冗余的检入示例。项目没有进行任何更改。http://ow.ly/d/1g7 - Sasha O
2
Sasha，这是我看到的内容：
  • 添加或更改库的范围。 当团队中的1人将库添加到项目中时，我希望其余9名开发人员能够获得此更新，而不是手动解决此问题。
  • /target/work现在不再被排除。同样，我希望这种变化能够传播。
  • 编译器设置更改。我不确定，可能是IDEA版本升级的产物或者是一次有意的更改。
 - alexei.vidmich
Alexei，就像我之前说的一样，这个项目没有做任何更改，但是 IDEA 不知怎么地却决定改变了文件。也许这是因为不同的开发人员使用不同版本的 IDEA 所导致的，但我不想指定开发人员必须使用某个特定版本的软件。无论如何，我认为我找到了更好的解决方案。我正在尝试它，几天后会有报告。 - Sasha O
你一直在调查什么更好的解决方案，Sasha？ - Gilles Philippart
我现在正在一个项目中，没有标准的IDE构建会导致不同开发人员之间的一些痛苦。像Alexei在这里建议的那样，将大多数.idea文件放入源代码控制是一个非常好的主意。 - David J.
显示剩余2条评论
9

我看到标准答案是“不要检入项目文件，只需检入.pom文件”。但是像.ipr文件之类的文件包含了许多有用的设置，这些设置无法从.pom文件中派生。如果其他IntelliJ用户想分享这些设置呢？我知道.ipr文件是被设计成可以进行版本控制的（例如，参见此线程）。我希望能给出一个确切的答案，但我还没有找到一个好的实践方法。

1
我正在使用.idea目录布局，这应该更符合版本控制的要求。但每次都有很多变化，如果不小心就会污染版本控制历史记录。我想尝试的一个可能性是将.idea放在svn:ignore中，但需要不时手动进行检查。对于.eclipse的.classpath和.project文件也是同样的方法。 - Sasha O
这似乎更像是一个问题而不是答案。我认为这应该作为对另一个答案的评论。 （抱歉，我知道这样说让我有点像“Stack Overflow程序警察”，但如果人们正确使用系统，系统确实运作得很好。所以去投票反对你认为是错误的答案，并投赞成票给你喜欢的答案。我认为Alexei比其他人更正确地回答了这个问题，所以我给他投了赞成票，其他人则投了反对票。） - David J.
3
我的观点是，我们应该将任何IDE特定的文件保持在版本控制之外。这个想法是，我们应该尽可能保持IDE独立形式的信息，例如Maven pom文件等等。所有关键项目设置都可以在那里保存。既然所有重要的项目设置都保存在pom文件中，我不认为有任何严重理由来检查不仅IDE项目配置，而且任何其他IDE特定的配置。此外，“.idea”文件夹样式的项目配置真正污染了变更集日志。如果我们仍然希望将IDEA项目设置保存在版本控制中，我们至少可以将它们存储在单个.ipr文件格式中。
如果目标是帮助开发团队使用共享的IDE配置，将大部分.idea文件放入源代码控制中是一个绝佳的主意。我看到alexi.vidmich在他的回答中理解了这一点。 - David J.
我在某种程度上同意这个观点，但它仅适用于不涉及任何底层系统细节（如绝对路径、运行时环境等）的配置。 - Maksym Govorischev
1
我来晚了，但这个问题一直困扰着我。不过我刚有了灵感，至少对于我们的源代码控制系统来说是可行的。
IntelliJ文件不必与权威的pom.xml和源代码“放在一起”存储。如果那些与源代码无关的更改记录到源代码树中的另一个位置，版本控制历史就不会被“污染”。
因此，我将尝试将IntelliJ文件移动到版本控制系统中的一个平行位置，使用简单的文件/目录映射在开发人员的机器上重新统一源代码和项目文件，并监视版本控制系统中纯粹影响构建的文件的更改。
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接