问题
The IntelliJ 2017.2 documentation suggests including the .idea folder that contains that IDE’s own configuration files (excepting the workspace.xml and tasks.xml files). I can understand the sense in this, as I could incorrectly configure the project settings and want to revert.
Yet, I want to post this open-source multi-module Maven-driven project to BitBucket for public access. Obviously, not everybody uses IntelliJ as their IDE, so I do not want to force my IDE settings on them.
➠ How do open-source authors resolve this conundrum?
回答1:
My suggestion that comes from experience is to always explicitly ignore (that is, add to .hgignore or .gitignore) IDE configuration files or directories.
It is not only a question of not spamming a project with configuration files for a specific IDE. The real problem begins when more that one person uses the same IDE. Depending on the IDE and on how it is configured, you can fall in a situation where each commit contains changes to these files, and will confuse all the other developer using the same IDE, which in turn will overwrite the changes again in a infinite loop.
Some of your IDE settings will be global and stored in your home directory. The ones that are project specific will survive as long as you don't change the local directory in which you cloned the repo. If you change directory, in my experience it is always tolerable to reconfigure the IDE. There are at least two situations when the local directory changes: (1) you remove the directory and clone the repository again (2) you use more than one computer.
If you are concerned for things like coding style, then the best approach is to use a command-line formatter tool that works for any editor or IDE. That tool will have its configuration file committed in the repo, since coding style is something that should be equal for all developers and files of a repo.
来源：https://stackoverflow.com/questions/46499525/include-exclude-ide-specific-configuration-files-from-mercurial-version-control