该项目正在使用Maven，因此POM文件是项目信息的主要来源。项目文件中有一些有用的设置，这些设置很好。
OTOH IDEA似乎在项目文件结构中创建了太多冗余更改，这些更改会污染SVN历史记录，有时会产生冲突。
我应该将.idea目录和* .iml文件保留在版本控制下吗？在全？部分？
更新：所以我发现为我和我的团队工作的最佳做法是：
这样，您可以将.idea目录的内容保留在版本控制中，但不要使其不受常规提交的影响。任何开发人员都可以访问任何其他人的IDEA目录。
更新2：由于这个问题已经写好，我已经将我的练习改为不将任何IntelliJ文件检入版本控制，正如许多响应者所建议的那样。这是我目前对Maven和Gradle的做法。这些工具已发展到可以始终从原始.POM或.gradle文件中重现关键信息。当文件发生变化时，IDE会可靠地跟踪更改，因此您不会丢失IDE文件，因此无需检查它们。
更新3：在提出这个问题7年之后，似乎仍然具有相关性。同样的最佳实践也适用于Gradle（也可能是SBT）：不要检查IDE文件，必要时从基本的POM，.gradle或SBT文件中重新创建它们。
答案 0 :(得分：17)
简短回答：不要将这些文件放在源代码控制存储库中，因为你可以“生成”它们（如果你不需要它们，如果它们很烦人，如果它们可以打破其他环境则更是如此）。
我个人对svn:ignore使用以下值：
target
*~
*.log
.classpath
.project
*.ipr
*.iws
*.iml
.settings
答案 1 :(得分：15)
Maven的一大优点是，工具支持用于将POM转换为Eclipse，Idea和Netbeans中的本机项目。如果你有一个pom，你可以很快地创建一个原生项目。
出于这个原因，我不会检查源代码控制下的.idea或* .iml文件，而不是检查RMI存根或类文件。
答案 2 :(得分：14)
我认为你应该把.idea目录放到版本控制中。其中包含的大多数配置都应该跟踪版本，例如编译器配置。
唯一不属于版本控制的文件是.idea / workspace.xml，因为它只包含特定于本地环境的配置。
IntelliJ Idea实际上默认将workspace.xml放入忽略列表中，因此如果您使用Idea进行签入，则应该在不更改任何内容的情况下进行设置。
答案 3 :(得分：9)
我看到标准答案是“不要检查项目文件，只检查.pom”。但是像.ipr文件这样的东西包含许多无法从.pom文件派生的有用设置。如果IntelliJ用户想要分享这些设置怎么办？我知道.ipr文件设计为版本化（例如，参见this thread）。我希望我有一个实际的答案，但我还没有找到一个很好的做法。
答案 4 :(得分：3)
我的意见是我们应该保留任何IDE特定文件不受版本控制。我们的想法是，我们应该尽可能多地保留IDE独立形式的信息，如Maven pom文件等。所有关键项目设置都可以保留在那里。并且将所有主要项目设置保存在pom文件中我没有看到任何严重的理由不仅要检入IDEA项目配置，还要检查任何其他IDE特定配置。此外，.idea文件夹样式项目配置确实污染了变更集日志。我们仍然希望将IDEA项目设置保留在版本控制中，我们至少可以将它们存储为单个.ipr文件格式。
答案 5 :(得分：1)
我参加这个派对已经迟到了，但这个问题一直困扰着我。而我的灵感来自于我认为可以起作用的东西，至少是我们的源控制系统。
IntelliJ文件不必与权威的pom.xml和源“一起”存储。如果将那些与非源相关的更改记录到源树中的其他位置，则版本控制历史记录不会“被污染”。
因此，我将尝试将IntelliJ文件移动到版本控制系统中的并行位置，使用简单的文件/目录映射来重新启动开发人员计算机上的源文件和项目文件，并监视版本控制系统中纯粹的更改影响构建的文件。