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.

Solution 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.

Solution 2

From official DOC: http://devnet.jetbrains.com/docs/DOC-1186

Depending on the IntelliJ IDEA project format (.ipr file based or .idea directory based), you should put the following IntelliJ IDEA project files under the version control:

.ipr file based format

Share the project .ipr file and and all the .iml module files, don't share the .iws file as it stores user specific settings.

.idea directory based format

Share all the files under .idea directory in the project root except the workspace.xml and tasks.xml files which store user specific settings, also share all the .iml module files.

I put it in my .gitignore:

#Project
workspace.xml
tasks.xml

Solution 3

An official answer is available. Assuming you're using the modern (and now default) .idea folder project format:

• Add everything...
• Except .idea/workspace.xml (which is user-specific)
• Except .idea/tasks.xml (which is user-specific)
• Except some other files that might contain passwords/keys/etc (see above link for details)

This sample .gitignore file might be a useful reference, though you should still read the above link to understand why these entries appear and decide if you need them.

Personally I also ignore the .idea/find.xml file as this seems to change every time you perform a search operation.

Solution 4

I took workspace.xml out of source control (+ added to .gitignore).

Solution 5

Our team doesn't check in path-specific IntelliJ files. We assume that people know how to use the IDE and set up a project. IntelliJ files go into the 'ignored' change list.

UPDATE:

The answer is easier now that I'm using Maven and its default directory structure.

IntelliJ should be asked to ignore all files in /.svn, /.idea and /target folders. Everything pertaining to an individual's path information is stored in /.idea.

Everything else is fair game to be committed to Subversion or Git.

View more solutions

Comments

[Matthew Cornell]

see stackoverflow.com/questions/3041154/… -> IDEA FAQ: devnet.jetbrains.com/docs/DOC-1186

[WernerCD]

Answer below provided gitignore.io as a good base. I found it useful, even if three years after the fact: gitignore.io/api/java,android,eclipse,intellij

[Admin]

Note that the IDEA issue youtrack.jetbrains.com/issue/IDEA-64312 I mentioned is marked as fixed in IntelliJ IDEA 14, so those using the latest version and wanting to keep the files in source control may have a better time of it now than at the time I posted this question.

[Admin]

Setting up the project isn't a big deal as it doesn't happen often, but it's very handy to be able to share build configurations and inspections profiles without needing to email screenshots around or something.

[duffymo]

Check in the stuff that isn't dependent on an individual's path.

[Admin]

Moving to the directory-based structure definitely helped a lot. We took the .iml files out of source control, which makes IDEA a little confused when checking out for the first time, but it does seem the best compromise for now. We also had to have the TeamCity inspections work off of the Maven file and an exported inspections profile, but we got that working too. Thank you!

[Admin]

Yes, and as I said in the question we shared the .ipr and .iml and not the .iws. The problem is the issue in youtrack.jetbrains.com/issue/IDEA-64312 that the .iml files change all the time, leading to frequent conflicts. Keeping the .iml files out of source control seems to work better for us, since IDEA regenerates them from the Maven POM, and then they can just keep changing locally without conflicts with other developers. Thanks!

[Felipe]

With this approach we have problem with some resource names, for example: Android JDK versions. Some of our team's member has different names or different versions to a configured SDK. Sending project files to repo you need to align that kind of things with your team. Until yesterday we did not was used to send proj files to repo, but it become hard because our project become big and hard to configure.

[Kumait]

Unifying used SDKs and relative paths is the simple and effective solution

[Felipe]

Yes. Now all our modules point to "Project SDK", and we align with the team to use the same SDK. At least is just one place to modify. But IntelliJ could do it better.

[WernerCD]

based on the "sample gitignore file" link, I would take it a step further and am glad you provided this. go to the based address and you can combine different types to get a "full" gitignore. For my Android project, which uses, obviously, Java, Android, Eclipse, IntelliJ: gitignore.io/api/java,android,eclipse,intellij

[Ben.12]

The link is broken. Not sure what the original content was, but here is a link to a relevant doc on IDEA's project structure. And here is another link dealing with this specific issue.