IntelliJ IDEA 9 的最佳实践梅文 +版本控制
该项目使用 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 文件重新创建它们。
The project is using Maven so the POM files are the main sources of project info. There are some useful settings in the project files which would be nice to keep.
OTOH IDEA seems to create too many redundant changes in the project file structure which pollutes the SVN history and sometimes creates conflicts.
Should I keep the .idea directory and the *.iml files under version control? in full? in part?
Update: So the best practice I have found working for me and my team is so far:
- Check in all IDEA files, *.iml and .idea directories. They contain valuable information and it's a waste of time to recreate it each time you update.
- Create private branch for every developer
- cd into .idea directory
- svn switch it to its private branch counterpart
- Don't check in IDEA files on regular commits -- they pollute history. Check them in on special commits.
This way, you keep the content of .idea directory in version control but keep it out of the way of regular commits. Any developer can have access to anybody else's IDEA directories.
Update 2: Since this question was written, I have changed my practice to not checking in any IntelliJ files into the version control, as advised by many responders. This is my current practice for both Maven and Gradle. The tools have developed to the point that the critical information can always be reproduced from the original .POM or .gradle files. When the files change, the IDE tracks changes reliably so you don't lose your IDE files that often so there is no need to check them in.
Update 3: 7 years after asking this question it seems to be still relevant. The same best practices apply to Gradle as well (probably SBT, too): don't check IDE files in, recreate them as necessary from the basic POM, .gradle or SBT files.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
简短的回答：不要将这些文件放在源代码控制存储库中，因为您可以“生成”它们（如果您不需要它们，如果它们很烦人，如果它们会破坏其他环境，则更是如此）。
我个人对 svn:ignore 使用以下值：
Short answer: don't put these files in the source control repository as you can "generate" them (and this is even more true if you don't need them, if they are annoying, if they can break others environment).
I personally use the following values for
svn:ignore:Maven 的一大优点是提供了将 POM 转换为 Eclipse、Idea 和 Netbeans 中的本机项目的工具支持。如果你有一个 pom，你可以很快创建一个原生项目。
因此，我不会在源代码管理下签入 .idea 或 *.iml 文件，就像不会签入 RMI 存根或类文件一样。
One of the great things about Maven is that the tool support exists for turning a POM into a native project in Eclipse, Idea and Netbeans. If you have a pom, you can create a native project pretty quickly.
For that reason, I wouldn't check in .idea or *.iml files under source control any more than I would check in RMI stubs or class files.
我认为你应该将 .idea 目录放入版本控制中。其中包含的大多数配置都应该进行版本跟踪，例如编译器配置。
唯一不属于版本控制的文件是 .idea/workspace.xml，因为它仅包含特定于本地环境的配置。
IntelliJ Idea 实际上默认将workspace.xml 放入忽略列表中，因此如果您使用Idea 签入，则应该已全部设置完毕，无需更改任何内容。
I think you should put .idea directory into version control. Most of the configuration contained there should be version tracked, e.g. compiler configs.
The only file that doesn't belong to version control is .idea/workspace.xml, because it only contains configuration particular to your local environment.
IntelliJ Idea actually puts workspace.xml into ignore list by default, so if you use Idea to check in, you should be all set without changing anything.
我看到标准答案是“不要签入项目文件，只签入 .pom”。但是 .ipr 文件之类的内容包含许多无法从 .pom 文件派生的有用设置。如果其他 IntelliJ 用户想要共享这些设置怎么办？我知道 .ipr 文件被设计为版本控制（例如，请参阅此线程）。我希望我有一个实际的答案，但我还没有找到关于这个问题的良好实践。
I see that the standard answer is "don't check in the project file, just the .pom". But things like the .ipr files contain lots of useful settings that can NOT be derived from the .pom file. What if fellow IntelliJ users want to share those settings? I know that .ipr files ARE designed to be versioned (see this thread for example). I wish I had an actual answer, but I haven't yet found a good practice on this matter.
我的观点是，我们应该将任何 IDE 特定文件排除在版本控制之外。我们的想法是，我们应该以独立于 IDE 的形式保留尽可能多的信息，例如 Maven pom 文件等。所有关键的项目设置都可以保存在那里。并且将所有主要项目设置都保存在 pom 文件中，我认为没有任何重要的理由不仅要检查 IDEA 项目配置，还要检查任何其他 IDE 特定配置。此外，.idea 文件夹样式的项目配置确实会污染变更集日志。而且我们仍然希望将 IDEA 项目设置保留在版本控制中，我们至少可以将它们存储为单个 .ipr 文件格式。
My opinion is that we should keep any IDE specific files out of Version Control. The idea is that we should keep as much as possible information in IDE independent form like Maven pom files and so on. All critical project settings can be kept there. And having all major project settings kept in pom file I don't see any serious reason to check in not only IDEA project configuration but any other IDE specific configuration. Additionally, .idea folder style project configuration really pollutes changeset logs. And we still want to keep IDEA project settings in version control, we can at least store them in single .ipr file format.
我参加这个聚会迟到了，但这个问题一直困扰着我。我只是受到了我认为可行的启发，至少对于我们的源代码控制系统来说是这样。
IntelliJ 文件不必与权威的 pom.xml 和源“一起”存储。如果那些与源无关的更改被记录到源树中的不同位置，则版本控制历史不会被“污染”。
因此，我将尝试将 IntelliJ 文件移动到版本控制系统中的并行位置，使用简单的文件/目录映射来重新统一开发人员计算机上的源文件和项目文件，并监视版本控制系统中纯粹影响文件的更改构建。
I'm late to this party, but this exact issue has been plaguing me. And I was just inspired with what I believe could work, at least with our source control system.
The IntelliJ files do not have to be stored "together" with the authoritative pom.xml and the source. The version control history is not "polluted" if those non-source related changes are recorded to a different place in the source tree.
So I will try moving the IntelliJ files to a parallel place in the version control system, use a simple file/directory mapping to reunify source and project files on developer machine, and monitor changes in the version control system that are purely to files that affect the build.