What Intellij config files should be kept in version control? Follow

Almost all files in .idea should be shared.
Personal data is only in workspace.xml (and maybe your personal dictionary in /dictionaries).

Thanks!

Also, do the iml files go in source control?

Sure, .iml describes project module, if somebody changes it (adds new library for example), other team members must be aware immediately to avoid problems (e.g. broken compilation)

This is generally NOT a good idea. Your project should be IDE-agnostic. Ideally, you configure your project with something like Maven and store your POM files as part of your sources. Then any developer can check out the sources and import them as a Maven project into any IDE. This will ensure consistency across multiple IDE types. Even if all developers on your team are using IntelliJ, there is a chance that people would end up with issues when they check out the sources with the native IDEA project config files. There is always a chance that something somewhere will be machine-specific, etc. Especially when it comes to directory structures, etc. Like I said, the safest thing is to use an IDEA-agnosting configuration, such as Maven.  Just s suggestion...

Maven or similar tools will never be able to provide all information your IDE needs to work with your project (e.g. IntelliJ IDEA's facet configurations). Actually it's quite common for mixed teams to have configuration files for all IDEs used by team checked into VCS.

This is not true. The Maven config is all you need. After I import the Maven project, IDEA normally would detect the Facets and prompt me to "configure" them, i.e. essentially confirm that I want it to recognize them. All the Spring, JPA, etc. configuration is already there in your source files - e.g. in your Spring config files, and IDEA sees them. All the dependencies are in your POM files. You just have to click to "accept" and IDEA will register them. You should not normally impose your IML or eclipse project files on others, there is no need for that, and that is error-prone.

This statement is true but only valid for small projects from my experience. Any decent sized project will have "exotic" configurations neither IDE will be able to pickup automatically.

I beg to differ. Consistency and IDE-agnostic configuration is by far more important on a large real-life project. It may be true that there are many over-sized and misconfigured projects that are a mishmash of all sorts of configurations and hacks. But that only proves my point. That is NOT how things should be. I usually deal with large enterprise projects. The Project Structure design and configuration is one of the most essential and important steps in the overal architecture/design/development process. Many teams treat that as an afterthought. Actually, most. The vast majority of legacy projects I see at client sites have flawed module and package structure, and that makes a huge impact on the whole development process, making things so much more difficult. Nothing is as important as the clarity and simplicity of modular organization and packaging. It allows you to properly decouple components, allow people to work on different modules concurrently without getting in each others way, reuse modules in multiple applications within the enterprise, etc. That is part of a thoughtful, intelligent architecture. Except stuff like that is most often overlooked and is treated as an afterthought. Often the "package structure" is imposed on the development team by a beuraucrat-architect who knows little about coding... Ah well... Just venting. But, trust me, a clean project structure/design does not need (and must not need) any dependency on native IDE-specific configurations.

I concur, keep everything in version control except your workspace.xml. Just mark that as ignored as appropriate for your version control system.

We have both IntelliJ and Eclipse project files in our projects. It works just fine. Not keeping IDE config files in version control is complete nonsense.

If those aren't kept in version control that means everytime I create a branch and checkout that branch I have to recreate all of my run configurations and totally setup the project again. That is a complete and utter waste of time.

Just keep the project files in version control.

Yeah very old post but it's not just workspace.xml that I would need to add to .gitignore should my team have commited .idea, I don't want my deployment.xml overwritten for my SSH interpreter set up for Python. Is there a list of files that we know shouldn't be added to version control, of do I just simply look in all of them? 

See https://intellij-support.jetbrains.com/hc/articles/206544839.

Thanks Serge, the starter .gitignore link in that article is helpful.

And now that I'm aware, I should check for other files plugins may add to the .idea directory like the deployment.xml that gets generated when I create an SSH interpreter for remote Python work.