How to manage projects under Version Control Systems
To share IDE project files with other developers, follow the guidelines below.
Default project format (.idea directory)
Directory-based. The default format used across all present-day versions of Intellij-based IDEs.
What needs to be shared:
- All files under the .idea directory in the project root except the items that store user-specific settings:
- workspace.xml
- usage.statistics.xml
- shelf directory
- All the .iml module files (can be located in different module directories) -> applies to IntelliJ IDEA
Note that starting with version 2019.1, IntelliJ is capable of adding everything that needs sharing to Version Control automatically.
Items you need to be cautious about:
- Android artifacts that produce a signed build (will contain keystore passwords)
- In IDEA 13 and earlier, the dataSources.ids and datasources.xml files can contain database passwords. IDEA 14 solves this problem.
Items you may want to exclude from sharing:
- .iml files and .idea/modules.xml file for the Gradle or Maven based projects since these files will be generated on import
- gradle.xml file, see this discussion
- user dictionaries folder (to avoid conflicts if other developer has the same name)
- XML files under .idea/libraries in case they are generated from Gradle or Maven project
Legacy project format (.ipr/.iml/.iws files)
File-based. Outdated and not recommended for use.
- Share the project's .ipr file and all the .iml module files.
- Do not share the .iws file as it stores user specific settings.
For Git, you can use this .gitignore as the starting point.
Please sign in to leave a comment.
In WebStorm the configurations for the project are stored in workspace.xml.
The configurations are needed to start, build, debug and test the project (among others).
And, in my opinion, belong to the project not to the singledeveloper.
How can I share the configurations without sharing other users setting?
Thanks
Make the run configuration shared, see https://stackoverflow.com/a/3136255/104891 .
These instructions are far from complete. What should I do with all the folders like shelf etc? How on earth it can be so difficult to share IntelliJ configs in git? VSCode has made good job on this front.
workspace.xml contains many useful components like FileColors, Scopes, PhpServers, RunManager. At the same time it has too much user specific garbage like tasks (even if I don't work with tasks specially), changeList. These two points crossing out possibility to put this XML under version control. Even there is no possibility to expel some settings into separate file. Or I don't know how?
Can the following files safely be excluded through .gitignore when using a Gradle project?
What do you think?
The files generated on import and not having any manual customizations can be safely excluded from the version control.
Just thought I'd comment I'm having problems with misc.xml as well. My main reason for including .idea into VCS is so that other developers can clone the project and open up PyCharm with all the default configs set without headache and can start developing right away. I also like the idea of having a .idea/local so we know exactly what can be put into .gitignore. Serge Baranov, is there a list of files that are generated upon import that we can exclude from VCS?
I somhow changed the vcs root to the folder I have all my projects in and some of the files are marked red, I am guessing I did something wrong by changing the root can someone help me restore the default settings
Seems that this approach is not fully mature: in `compiler.xml` I get conflicts about different JDK versions, in misc.xml the JDK version name is also user specific. Also if team mates do use different plugins there will also be conflicts. I wonder if that will be fixed some time...
Thanks T Zillinger! Let me know what you find. We have the exact same issue with that attribute and version control.
What about other jetbrain tools. In https://github.com/github/gitignore/blob/master/Global/JetBrains.gitignore there is a section about ignoring .idea/modules and iml files if gradle autoimport is enabled. But i you use teamcity inspection the gradle build type seams not to work if iml-files are missing. It just dropps to 0 inspection errors.
This page seems out of date with respect to IDEA 2020, and could stand to be re-written.
sounds like this is broken by design. obviously jetbrains devs don't use their own products or don't have enough testing to understand the variety of needs for different teams. I wonder what VSCode looks like in this space.
Well, in a perfect world Maven and IntelliJ would be feature complete and share the same set of functionalities. But we are not yet there (and we will never get there?). So in practice we need to configure things both in IntelliJ and in Maven. I.e., we need such configuration files for IntelliJ and it would be helpful if we can put some of them (that are project dependent) into VCS and those that are user dependent in ignore files. But IntelliJ still mixes up those different file types (for quite some years now).
How about runConfigurations? Can it be shared?
Mark Vedder I've discovered the change concerning the separate .run folder in v2020.1 as well and I welcome the change very much. But what I don't understand is, how does IntelliJ determine the "default" when I click on "Store as project file"? We have had projects where it pre-assigned .run as the value and others where .idea/runConfigurations was chosen. To me the behavior looks completely random currently, as I don't understand it yet. Also a fresh Maven project I just created also did pre-assign the old location instead of the new one. Where does the "default" come from? Is it configurable?
I am using the newest IntelliJ version 2021.1.1
@... If the project is under version control and the .idea directory (or the .idea/runConfigurations directory) is ignored, it will suggest the {projectRoot}/.run Otherwise it will suggest the .idea/runConfigurations This blog post discusses the behavior. Unfortunately, if you are not under version control or the directory is not ignored, even if you have a {projectRoot}/.run directory with stored configs (say from a previous save), it will not default to suggesting the {projectRoot}/.run directory. But it will be listed in the drop down of potential save locations.
To the best of my knowledge -- and after having looked through the actual source code in IntelliJ IDEA when implementing the saving of run configurations for a new project wizard in the plugin I write -- no it is not configurable.
In the end, I think that is the best strategy. It is what we do as well in the rare cases we want to share any IDE configs (although most of the time we do not). This is especially useful since plugins can add files to the .idea folder. This can cause issues if one dev has a plugin installed, and another does not. Or if it is a plugin that is best to not share configs for. And it is much easier to later enable the sharing of something when it is determined it is best to do so then to try and add a file to the ignore list after its been shared, because inevitably some dev goes to delete it from their local workspace, but deletes it from git and causes issues for the other dev(s) that need/use it.
How about jetbrains publishes a few versions of gitignore.. from basic android to some of the more exotic requirements. There's a few floating out there, but none are official from jetbrains that i could find.
The first item of the article should be less categorical and include the caveat from the .gitignore mentioned at the end:
Link here is wrong:
Should be this: https://www.jetbrains.com/help/idea/configure-project-settings.html#share-project-through-vcs
My .idea/misc.xml is under version control keeps getting overwritten by intellij. Any advice?
What are the specific changes that occur to this file?
Is it a Maven or Gradle project? What Java language level is set for the project in the build file?
Gradle with build.gradle.kts
tasks.withType<JavaCompile> {sourceCompatibility = "17"
targetCompatibility = "17"
}
So it's expected that it changes to languageLevel="JDK_17". Just commit this change and it should not be an issue again.
Could we have some clarification on the Gradle files? Specifically this line:
Is this still accurate? What if you need to mark a directory as source or generated source or something like that and need to share that with your team?
Timothyfroehlich Current IDE versions do not even save
.imlfiles in the project for Maven and Gradle. Yes, it's still accurate. Source roots are defined via the build file.Serge Baranov Thanks for the quick response! That's what I'm confused about. I'm using Android Studio Koala Feature Drop | 2024.1.2 Canary 4, so that's IntelliJ 2024.1.2, and I right-clicked on a directory to mark it as source, and afterwards I had an `.iml` file in my `.idea/modules/` directory that records the directory as source. So for my situation, I needed to include `.idea/modules.xml` and `.idea/modules` in my source control. Even though the directory is included as source in one of my build files I still needed to add it manually. Am I doing the right thing here?
Timothyfroehlich No, your changes to the project structure will be discarded on the next project re-import/refresh.
To add additional source roots via Gradle, see https://stackoverflow.com/questions/28345705/how-can-i-add-a-generated-source-folder-to-my-source-path-in-gradle .