How to deal with IntelliJ IDEA project files under

问题:

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 settingss 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 StackOverflow 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.

Thank you.

回答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.

回答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

回答3:

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

• Add everything...
• Except .idea/workspaces.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.

回答4:

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

回答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.

回答6:

Just to share another approach my team have used: Just move whatever IDE related files to a different location where IntelliJ doesn't recognize, and create a script to copy them to desired 'active' location that is ignored by GIT.

The benefit of this approach is that you kept the option of sharing IDE settings through version control. The only drawback is you have to decide when to run the script (probably once per workspace clone or when changes are desired), and you can automate this through incorporating the script in your build process or post-merge hook.

This approach relies on that IntelliJ searches only particular locations for its setting files, so it applies with framework configuration files also. Actually we ignored Grails .properties file the same way, so developers won't accidentally check-in their local configuration changes.