Best practices for IntelliJ IDEA 9 + Maven + Version control

Question

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:

1. 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.
2. Create private branch for every developer
3. cd into .idea directory
4. svn switch it to its private branch counterpart
5. 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.

Answer 1

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:

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

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.