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

【问题标题】：Best practices for IntelliJ IDEA 9 + Maven + Version controlIntelliJ IDEA 9 + Maven + 版本控制的最佳实践
【发布时间】：2010-12-11 22:26:42
【问题描述】：

该项目使用 Maven，因此 POM 文件是项目信息的主要来源。项目文件中有一些有用的设置可以很好地保留。

OTOH IDEA 似乎在项目文件结构中创建了太多冗余更改，从而污染了 SVN 历史记录，有时还会产生冲突。

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

更新：到目前为止，我发现对我和我的团队最有效的做法是：

检入所有 IDEA 文件、*.iml 和 .idea 目录。它们包含有价值的信息，每次更新时重新创建它是浪费时间。
为每个开发者创建私有分支
cd 进入 .idea 目录
svn 将其切换到其私有分支对应项
不要在定期提交时签入 IDEA 文件——它们会污染历史记录。在特殊提交时检查它们。

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

更新 2： 自从写了这个问题以来，我已经改变了我的做法，不将任何 IntelliJ 文件签入版本控制，正如许多响应者所建议的那样。这是我目前对 Maven 和 Gradle 的实践。这些工具已经发展到可以始终从原始 .POM 或 .gradle 文件中复制关键信息的程度。当文件更改时，IDE 会可靠地跟踪更改，因此您不会经常丢失 IDE 文件，因此无需签入。

更新 3： 在提出这个问题 7 年后，它似乎仍然具有相关性。相同的最佳实践也适用于 Gradle（可能也是 SBT）：不要签入 IDE 文件，必要时从基本 POM、.gradle 或 SBT 文件重新创建它们。

【问题讨论】：

感谢大家的建议。与此同时，我的最佳做法是检查 IDEA 文件，但将其作为单独的变更集进行检查，以免严重破坏 SVN 历史记录。我通常将这些变更集命名为“IDEA madness”:-)
参见stackoverflow.com/questions/3041154/… -> IDEA 常见问题解答：devnet.jetbrains.com/docs/DOC-1186
@MatthewCornell 也许升级你的评论来回答？

标签： intellij-idea gradle version-control sbt maven-2

【解决方案1】：

简短的回答：不要将这些文件放在源代码控制存储库中，因为您可以“生成”它们（如果您不需要它们，如果它们很烦人，如果它们会破坏其他环境，则更是如此）。

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

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

【讨论】：

这个答案忽略了在签出/更新后立即拥有 iml 文件的价值。我看到开发人员浪费了很多时间，他们必须弄清楚，他们需要在之后重新生成 iml更新。把他们放到VC里面其实是对别人好。盲目地遵循一般的“不提交生成的东西”规则只会在这里造成伤害。
除非我离这里很远，否则 .idea 目录中的许多设置不能简单地重新生成。我们正在讨论如何将项目拆分为模块，哪些模块附加了哪些方面，需要生成哪些工件，构建过程是什么等。这是关键信息。现在，如果您可以从其他文件中生成所有这些信息，那么请考虑采用该路线，但对于这里的问题，我没有看到。
这不适用于涉及很多人的大型项目。例如，在我们的例子中，我们还将idea执行的检查和代码格式样式存储在那里。
实际上，IDEA Project (.ipr) 和 IDEA Module (.iml) 文件是为共享而设计的，因此您应该将它们签入源代码管理。还有一个不应共享的 IDEA Workspace (.iws) 文件。

【解决方案2】：

Maven 的一大优点是该工具支持将 POM 转换为 Eclipse、Idea 和 Netbeans 中的本机项目。如果你有一个 pom，你可以很快地创建一个原生项目。

因此，我不会在源代码控制下签入 .idea 或 *.iml 文件，就像签入 RMI 存根或类文件一样。

【讨论】：

+1 提到在团队中使用多个 IDE 时的好处

【解决方案3】：

我认为您应该将 .idea 目录放入版本控制中。那里包含的大多数配置都应该跟踪版本，例如编译器配置。

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

IntelliJ Idea 实际上默认会将workspace.xml 放入忽略列表，所以如果你使用Idea 签入，你应该在不改变任何东西的情况下全部设置。

【讨论】：

这实际上是原始问题的原因：.idea 是我使用的（当然没有 workspace.xml），它一直在产生变化。这些变化搅乱了历史，让我处理得太多。我怎样才能减少这些变化？
我使用这种方法几天，并没有注意到该区域有任何不必要的变化。您是否有所谓的冗余更改污染 SVN 历史记录的示例，这些更改位于 .idea 目录下但在 workspace.xml 之外？
Alexei，这里是冗余签入的一个示例。没有对项目进行任何更改。 ow.ly/d/1g7
Sasha，这是我所看到的： - 添加或更改库的范围。当团队中 10 人中有 1 人向项目添加库时，我希望其余 9 名开发人员获得此更新，而不是手动解决此问题。 - /target/work 不再被排除在外。同样的事情，我希望这种变化能够传播。 - 编译器设置更改。不确定，可能是 IDEA 版本升级的产物或故意更改。
Alexei，正如我所说，根本没有对项目进行任何更改，但 IDEA 不知何故决定更改文件。可能发生这种情况是因为不同的开发人员使用不同版本的 IDEA，但我不想规定某个版本的软件供开发人员使用。无论如何，我想我找到了更好的解决方案。我正在尝试，过几天报告。

【解决方案4】：

我看到标准答案是“不签入项目文件，只签入 .pom”。但是 .ipr 文件之类的内容包含许多无法从 .pom 文件派生的有用设置。如果其他 IntelliJ 用户想要共享这些设置怎么办？我知道 .ipr 文件被设计为版本控制（例如，参见this thread）。我希望我有一个实际的答案，但我还没有找到关于这个问题的好的做法。

【讨论】：

我正在使用 .idea 目录布局，它应该对 VC 更友好。如果你不小心的话，每次仍然有很多变化会污染 VC 历史。我想尝试的一种可能性是将 .idea 放在 svn:ignore 下，但不时根据需要手动检查它。 .classpath 和 .project Eclipse 文件也是如此。
这似乎更像是一个问题而不是一个答案。我认为这属于对另一个答案的评论。（抱歉，我知道这样说让我有点像“堆栈溢出程序警察”，但如果人们正确使用该系统，该系统会运行得非常好。所以请投下你认为错误的答案，并投上你喜欢的答案。我认为阿列克谢比其他人更正确地回答了这个问题，所以我投了他赞成票，其他人投了反对票。）

【解决方案5】：

我的意见是我们应该将任何 IDE 特定文件排除在版本控制之外。我们的想法是，我们应该尽可能多地以独立于 IDE 的形式保存信息，例如 Maven pom 文件等。所有关键的项目设置都可以保存在那里。并且将所有主要项目设置保存在 pom 文件中，我认为没有任何理由不仅要检查 IDEA 项目配置，还要检查任何其他 IDE 特定配置。此外，.idea 文件夹样式的项目配置确实会污染变更集日志。而且我们仍然希望将 IDEA 项目设置保留在版本控制中，我们至少可以将它们存储为单个 .ipr 文件格式。

【讨论】：

如果目标是帮助开发团队使用共享的 IDE 配置，将大部分 .idea 文件放入源代码控制是一个好的想法。我看到alexi.vidmich 在他的回答中理解了这一点。
我可以部分同意这一点，但这仅适用于不涉及任何底层系统细节（如绝对路径、运行时环境等）的配置。

【解决方案6】：

我参加这个聚会迟到了，但这个确切的问题一直困扰着我。我只是受到了我认为可行的东西的启发，至少在我们的源代码控制系统中是这样。

IntelliJ 文件不必与权威的 pom.xml 和源“一起”存储。如果将这些与源代码无关的更改记录到源代码树中的不同位置，则版本控制历史不会“被污染”。

所以我将尝试将 IntelliJ 文件移动到版本控制系统中的并行位置，使用简单的文件/目录映射来重新统一开发人员机器上的源文件和项目文件，并监控版本控制系统中纯粹的更改影响构建的文件。

【讨论】：