如何在不断变化的Git源代码管理下处理IntelliJ IDEA项目文件？

我们团队中的每个人都使用IntelliJ IDEA，我们发现将其项目文件（.ipr和.iml）放入源代码管理非常有用，这样我们就可以共享构建配置，设置和检查。另外，我们可以在TeamCity的连续集成服务器上使用这些检查设置。（我们在.gitignore文件中而不是在源代码管理中有每个用户工作区的.iws文件。）

但是，当您在IDEA中几乎执行任何操作时，这些文件几乎不会更改。在IDEA的问题数据库中存在一个问题（IDEA-64312），因此也许有人会认为这是IDEA中的一个错误，但是在可预见的将来，我们需要与它一起解决这个问题。

直到最近，我们仍在使用Subversion，但是最近我们切换到了Git。我们每个人都已经习惯于拥有一个被忽略并且不会检入的项目文件的更改列表，除非存在我们要与他人共享的项目文件更改。但是使用Git，真正的力量似乎是（根据我们的探索）它所鼓励的连续分支，并且在分支之间进行切换非常麻烦，因为项目文件总是被修改。通常，它只能以某种方式合并更改，并尝试处理现在应用于新分支的项目文件更改。但是，如果新分支更改了项目文件（例如，该分支正在其他分支中尚未使用的新模块上工作），则git只会抛出一个错误，即它不会 当两个分支都已更改并且您在本地进行更改时，合并在文件中没有任何意义，我可以理解它的意义。在命令行中，可以在“ git checkout”命令上使用“ -f”强制其抛出本地更改并使用分支的更改，但是（1）在IDEA（10.5.1）中使用Git Checkout GUI命令似乎没有这个选项可以找到，因此我们需要定期切换到命令行，并且（2）我们不确定是否要习惯于使用该选项标记并告诉Git放弃我们的本地更改。

因此，这是我们对必须处理的选项的一些想法：

1. 将项目文件完全移出源代码管理。将它们放在.gitignore中，然后通过其他方式将它们分发给每个人和TeamCity，也许是通过将它们置于其他位置或使用其他名称的源代码控制中。我们的团队足够小，可以考虑这个选项，但这似乎并不好。
2. 继续使用它，尝试确保在给定时间管理我们在哪个分支上拥有哪些文件。为此，我们可能鼓励每个开发人员在他们的系统上拥有每个项目的多个副本，以便他们可以将每个项目检出到可能包含不同项目文件集的不同分支。
3. 尝试仅在源代码管理中包含项目（.ipr），而模块（.iml）文件不在源代码管理和.gitignore文件中。定期在.ipr中自动切换的主要问题是共享构建配置的顺序，但是也许我们可以单独共享有关如何设置这些信息的信息。我不太确定IDEA是如何处理这种事情的，尽管它只有一些文件，特别是在新结帐时。

我想我希望我们缺少一些显而易见的（或非显而易见的）解决方案，也许可以解决Git和IDEA似乎都具有的巨大可定制性。但是似乎我们不可能成为唯一遇到此问题的团队。是一种类似于Stack Overflow上的问题包括：3495191，1000512，和3873872，但我不知道，因为他们是完全一样的问题，也许有人能拿出的利弊我有不同的方法概述，这些问题的答案中列出的方法或它们建议的方法。

您可以使用IDEA的基于目录的项目结构，其中的设置存储在.idea目录中，而不是.ipr文件中。它可以对版本控制中存储的内容进行更细粒度的控制。.iml文件仍然存在，因此它不能解决它们中的随机更改（也许让它们脱离源代码控制？），但是共享诸如代码样式和检查配置文件之类的内容很容易，因为每个文件都可以在自己的.idea目录下的文件中。

从官方DOC：http : //devnet.jetbrains.com/docs/DOC-1186

根据IntelliJ IDEA项目格式（基于.ipr文件或.idea目录），应将以下IntelliJ IDEA项目文件置于版本控制下：

.ipr文件为基础的格式

共享项目.ipr文件和所有.iml模块文件，不要共享.iws文件，因为它存储了用户特定的设置。

.idea目录格式

共享项目根目录中.idea目录下的所有文件，除了工作区.xml和task.xml文件（它们存储用户特定的设置）之外，还共享所有.iml模块文件。

我把它放在我的.gitignore中：

#Project
workspace.xml
tasks.xml

可以提供官方答案。假设您使用的是现代（现在是默认）.idea文件夹项目格式：

• 添加所有内容...
• 除外.idea/workspace.xml（特定于用户）
• 除外.idea/tasks.xml（特定于用户）
• 除了其他一些可能包含密码/密钥/等的文件（有关详细信息，请参见上面的链接）

该示例.gitignore文件可能是有用的参考，尽管您仍应阅读上面的链接以了解为什么出现这些条目并决定是否需要它们。

我个人也忽略了该.idea/find.xml文件，因为每次执行搜索操作时该文件似乎都会改变。

我从源代码管理中删除了工作空间（xml添加到.gitignore中）。

我们的团队不会检入路径特定的IntelliJ文件。我们假设人们知道如何使用IDE并建立一个项目。IntelliJ文件进入“忽略”更改列表。

更新：

既然我正在使用Maven及其默认目录结构，答案就更容易了。

的IntelliJ应要求忽略中的所有文件/.svn，/.idea并且/target文件夹。与个人的路径信息有关的所有内容都存储在中/.idea。

其他所有东西都是致力于Subversion或Git的公平游戏。

只是分享我的团队使用的另一种方法：只需将所有与IDE相关的文件移动到IntelliJ无法识别的其他位置，然后创建脚本将其复制到所需的“活动”位置，该位置将被GIT忽略。

这种方法的好处是您可以选择通过版本控制共享IDE设置。唯一的缺点是您必须决定何时运行脚本（可能每个工作空间克隆运行一次或何时需要更改），并且可以通过将脚本合并到构建过程或合并后挂钩中来自动执行该脚本。

这种方法依赖于IntelliJ仅在特定位置搜索其设置文件，因此它也适用于框架配置文件。实际上，我们以相同的方式忽略了Grails .properties文件，因此开发人员不会意外签入其本地配置更改。