如何在Git源码控制下处理IntelliJ IDEA项目文件不断变化？
我们团队中的每个人都使用IntelliJ IDEA，我们发现把项目文件（.ipr和.iml）放到源代码控制中是很有用的，这样我们就可以共享构buildconfiguration，设置和检查。 另外，我们可以在TeamCity的持续集成服务器上使用这些检查设置。 （我们有.gitignore文件中的每个用户工作区.iws文件，而不是源代码pipe理。）
但是，当您在IDEA中执行任何操作时，这些文件几乎没有什么变化。 IDEA的问题数据库（ IDEA-64312 ）存在一个问题，所以也许有人可能会认为这是IDEA中的一个错误，但在可预见的将来，这是一个我们需要忍受的问题。
直到最近，我们还在使用Subversion，但是最近我们转向了Git。 我们每个人都习惯了有一个项目文件的更改列表，我们忽略了，没有检查，除非有项目文件的变化，我们想与他人分享。 但是对于Git来说，真正的力量似乎是（从我们正在探索的）中激发出来的连续分支，并且在分支之间切换是一个痛苦，项目文件总是被修改过。 通常它可以以某种方式在变化中合并，并尝试处理现在应用于新分支的项目文件更改。 但是，如果新分支已经改变了项目文件（比如分支正在处理一个不在其他分支中的新模块），那么git只会抛出一个错误，在文件中合并是没有意义的当两个分支都发生了变化，而且你在本地有了变化，我可以理解它的意思。 在命令行中，可以在“git checkout”命令中使用“-f”来强制它抛出本地修改，而是使用分支，但是（1）IDEA（10.5.1）中的Git Checkout GUI命令，似乎没有这个选项，我们可以find，所以我们需要定期切换到命令行，（2）我们不确定我们想要使用这个习惯标志并告诉Git抛出我们的本地变化。
所以，这里有一些想法，我们必须处理这个问题：
- 将项目文件完全从源代码pipe理中取出。 把它们放在.gitignore中，并通过其他方式将它们分发给每个人和TeamCity，也许把它们放在其他地方的源代码pipe理或其他名称下。 我们的团队足够小，这个选项是可行的，可以考虑，但似乎不是很好。
- 继续与它一起生活，试图确保在给定的时间pipe理哪些文件我们在哪些分支。 作为其中的一部分，我们可能会鼓励每个开发人员在他们的系统上拥有不止一个项目的副本，因此他们可以将每个项目签出到不同的分支，并且可能有不同的项目文件集合。
- 尝试在源代码控制中只包含项目（.ipr），而模块（.iml）文件不在源代码pipe理和.gitignore文件中。 定期在.ipr中切换的主要事情是共享构buildconfiguration的顺序，但是也许我们可以分别单独共享这些信息来设置它们。 我不太清楚IDEA如何处理这种只有一些文件的东西，尤其是在一个新的结账。
我想我希望有一些明显的（或非显而易见的）解决scheme，可能会涉及到Git和IDEA似乎都有的巨大的可定制性。 但似乎我们不可能成为唯一有这个问题的球队。 StackOverflow类似的问题包括3495191，1000512和3873872 ，但我不知道它们是完全相同的问题，也许有人可以拿出我所概述的各种方法的优点和缺点，这些问题的答案中列出的方法，或他们推荐的方法。
谢谢。
您可以使用IDEA的基于目录的项目结构 ，其中的设置存储在.idea目录而不是.ipr文件中。 它对版本控制中存储的内容提供了更精细的控制。 .iml文件仍然存在，所以它不能解决它们中的随机变化（可能使它们远离源代码pipe理？），但是共享诸如代码风格和检查configuration文件之类的东西很容易，因为它们中的每一个都是在.idea目录下的自己的文件中。
从官方DOC： http : //devnet.jetbrains.com/docs/DOC-1186
根据IntelliJ IDEA项目格式（基于.ipr文件或基于.idea目录），您应该将以下IntelliJ IDEA项目文件放在版本控制下：
基于.ipr文件的格式
共享项目.ipr文件和所有.iml模块文件，不要共享.iws文件，因为它存储用户特定的设置。
基于.idea目录的格式
共享项目根目录下.idea目录下的所有文件，除了存储用户特定设置的workspace.xml和tasks.xml文件外，还共享所有.iml模块文件。
我把它放在我的.gitignore：
#Project workspace.xml tasks.xml 官方的答复是可用的 。 假设您正在使用现代（现在是默认）的.idea文件夹项目格式：
- 添加一切…
- 除
.idea/workspaces.xml（这是用户特定的） - 除
.idea/tasks.xml（这是用户特定的） - 除了其他一些可能包含密码/键/等的文件（详见上面的链接）
这个示例.gitignore文件可能是一个有用的参考，虽然你仍然应该阅读上面的链接，以了解为什么这些条目出现，并决定是否需要它们。
就我个人而言，我也忽略了.idea/find.xml文件，因为每次执行search操作时都会改变它。
我把workspace.xml从源代码pipe理（+添加到.gitignore）。
我们的团队不检查path特定的IntelliJ文件。 我们假设人们知道如何使用IDE并build立一个项目。 IntelliJ文件进入“忽略”更改列表。
更新：
现在我正在使用Maven及其默认目录结构的答案更容易。
应该要求IntelliJ忽略/.svn /.idea和/target文件夹中的所有文件。 与个人path信息有关的一切都存储在/.idea 。
其他一切都是公平的游戏，致力于Subversion或Git。
只是分享我的团队使用的另一种方法：只要将任何IDE相关的文件移动到IntelliJ不识别的其他位置，并创build一个脚本将其复制到GIT忽略的所需“活动”位置。
这种方法的好处是你可以通过版本控制来共享IDE设置。 唯一的缺点是您必须决定何时运行脚本（可能每个工作区克隆需要一次，或者需要更改时），您可以通过将脚本合并到您的构build过程或合并后挂接中来自动执行此操作。
这种方法依赖于IntelliJ仅为其设置文件search特定位置，所以它也适用于框架configuration文件。 实际上，我们忽略了Grails .properties文件，所以开发人员不会意外地签入他们的本地configuration更改。
