How to deal with IntelliJ IDEA project files under Git source control constantly changing?

Question

Everyone on our team uses IntelliJ IDEA, and we find it useful to put its project files (.ipr and .iml) into source control so that we can share build configurations, settings, and inspections. Plus, we can then use those inspection settings on our continuous integration server with TeamCity. (We have the per-user workspace .iws file in the .gitignore file and not in source control.)

However, those files change in little ways when you do just about anything in IDEA. There's an issue in IDEA's issue database for it (IDEA-64312), so perhaps one might consider this a bug in IDEA, but it's one we'll need to live with for the foreseeable future.

Up until recently, we were using Subversion, but we recently switched to Git. We had each just gotten used to having a change list of project files that we ignored and didn't check in unless there were project file changes that we wanted to share with others. But with Git, the real power seems to be (from what we're exploring) the continuous branching that it encourages, and switching between branches is a pain with the project files always having been modified. Often it can just merge in the changes somehow, and tries to deal with the project file changes now being applied to the new branch. However, if the new branch has changed project files (such as the branch is working on a new module that isn't in the other branches yet), git just throws an error that it doesn't make any sense to merge in the files when both the branch has changes and you have changes locally, and I can rather understand its point. From the command line, one can use "-f" on the "git checkout" command to force it to throw out the local changes and use the branch's instead, but (1) the Git Checkout GUI command in IDEA (10.5.1) doesn't seem to have that as an option that we can find, so we'd need to switch to the command line on a regular basis, and (2) We're not sure we want to be in the habit of using that flag and telling Git to throw out our local changes.

So, here are some thoughts we have on options we have to deal with this:

1. Take the project files out of source control entirely. Put them in the .gitignore, and distribute them to each person and TeamCity via some other means, maybe by putting them in source control somewhere else or under other names. Our team's small enough this option is feasible enough to consider, but it doesn't seem great.
2. Continue living with it, trying to be sure to manage which files we have on which branches at a given time. As part of this, we might encourage each developer to have more than one copy of each project on their system, so they can have each checked out to a different branch with possibly different sets of project files.
3. Try having just the project (.ipr) in source control, with the module (.iml) files not in source control and in the .gitignore file. The main thing that seems to switch around on its own in the .ipr on a regular basis is the order of the shared build configurations, but maybe we can just share the information separately on how to set those up. I'm not quite sure how IDEA deals with this kind of thing of only having some of its files though, especially on a new checkout.

I guess I'm hoping there's some obvious (or non-obvious) solution we've missed, perhaps dealing with the huge customizability that Git and IDEA both seem to have. But it seems like we couldn't possibly be the only team having this problem. Questions that are kind of similar on Stack Overflow include 3495191, 1000512, and 3873872, but I don't know as they're exactly the same issue, and maybe someone can come up with the pros and cons for the various approaches I've outlined, approaches listed in the answers to those questions, or approaches that they recommend.

Answer 1

You can use IDEA's directory-based project structure, where the settings are stored in .idea directory instead of .ipr file. It gives more fine-grained control over what is stored in version control. The .iml files will still be around, so it doesn't solve the random changes in them (maybe keep them out of source control?), but sharing things such as code style and inspection profiles is easy, since each of them will be in its own file under the .idea directory.