Git源码控制下IntelliJ IDEA项目文件不断变化如何处理？答案

【问题标题】：How to deal with IntelliJ IDEA project files under Git source control constantly changing?Git源码控制下IntelliJ IDEA项目文件不断变化如何处理？
【发布时间】：2011-10-27 00:08:36
【问题描述】：

我们团队中的每个人都使用 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 丢弃我们的本地更改。

所以，对于我们必须处理的选项，我们有一些想法：

将项目文件完全脱离源代码管理。将它们放在 .gitignore 中，并通过其他方式将它们分发给每个人和 TeamCity，可能是将它们放在其他地方的源代码控制中或以其他名称。我们的团队足够小，这个选项足够可行，可以考虑，但似乎不太好。
继续使用它，尝试确保在给定时间管理我们在哪些分支上拥有哪些文件。作为其中的一部分，我们可能会鼓励每个开发人员在他们的系统上拥有每个项目的多个副本，这样他们就可以将每个项目签出到具有可能不同项目文件集的不同分支。
尝试仅将项目 (.ipr) 放在源代码管理中，模块 (.iml) 文件不在源代码管理中，而在 .gitignore 文件中。似乎在.ipr 中定期自行切换的主要内容是共享构建配置的顺序，但也许我们可以单独分享有关如何设置这些配置的信息。我不太确定 IDEA 如何处理这种只有部分文件的情况，尤其是在新结帐时。

我想我希望我们错过了一些明显（或不明显）的解决方案，也许是处理 Git 和 IDEA 似乎都具有的巨大可定制性。但似乎我们不可能是唯一有这个问题的团队。 Stack Overflow 上类似的问题包括3495191、1000512 和3873872，但我不知道，因为它们是完全相同的问题，也许有人可以提出优缺点我概述的各种方法、这些问题的答案中列出的方法或他们推荐的方法。

【问题讨论】：

参见stackoverflow.com/questions/3041154/… -> IDEA 常见问题解答：devnet.jetbrains.com/docs/DOC-1186
下面的答案提供了 gitignore.io 作为一个很好的基础。我发现它很有用，即使在事实发生三年后：gitignore.io/api/java,android,eclipse,intellij
请注意，我提到的 IDEA 问题 youtrack.jetbrains.com/issue/IDEA-64312 在 IntelliJ IDEA 14 中已标记为已修复，因此那些使用最新版本并希望将文件保留在源代码管理中的人现在可能会有更好的时间比我发布这个问题的时候。

标签： git version-control intellij-idea

【解决方案1】：

official answer is available。假设您使用的是现代（现在是默认）.idea 文件夹项目格式：

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

这个sample .gitignore file 可能是一个有用的参考，但您仍应阅读上面的链接以了解这些条目出现的原因并决定您是否需要它们。

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

【讨论】：

基于“示例 gitignore 文件”链接，我会更进一步，很高兴你提供了这个。转到基础地址，您可以组合不同的类型以获得“完整”的 gitignore。对于我的 Android 项目，它显然使用 Java、Android、Eclipse、IntelliJ：gitignore.io/api/java,android,eclipse,intellij

【解决方案2】：

您可以使用 IDEA 的 directory-based project structure，其中设置存储在 .idea 目录而不是 .ipr 文件中。与版本控制中存储的内容相比，它提供了更多 fine-grained control。 .iml 文件仍然存在，因此它不能解决其中的随机更改（也许使它们不受源代码控制？），但是共享代码样式和检查配置文件等内容很容易，因为它们中的每一个都将是在 .idea 目录下自己的文件中。

【讨论】：

转向基于目录的结构肯定有很大帮助。我们将 .iml 文件从源代码控制中移除，这让 IDEA 在第一次签出时有点困惑，但它似乎是目前最好的折衷方案。我们还必须让 TeamCity 检查工作脱离 Maven 文件和导出的检查配置文件，但我们也得到了这个工作。谢谢！
链接已损坏。不确定原始内容是什么，但here 是指向 IDEA 项目结构相关文档的链接。 here 是处理这个特定问题的另一个链接。

【解决方案3】：

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

更新：

现在我使用的是 Maven 及其默认目录结构，答案就更简单了。

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

提交给 Subversion 或 Git 的其他一切都是公平的游戏。

【讨论】：

设置项目没什么大不了的，因为它不经常发生，但是能够共享构建配置和检查配置文件非常方便，而无需通过电子邮件发送屏幕截图或其他东西。
签入不依赖于个人路径的东西。

【解决方案4】：

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

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

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

【讨论】：

【解决方案5】：

来自官方文档：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

【讨论】：

是的，正如我在问题中所说，我们共享 .ipr 和 .iml 而不是 .iws。问题是youtrack.jetbrains.com/issue/IDEA-64312 中的问题是 .iml 文件一直在变化，导致频繁的冲突。让 .iml 文件不受源代码控制似乎对我们来说效果更好，因为 IDEA 从 Maven POM 重新生成它们，然后它们可以在本地保持更改而不会与其他开发人员发生冲突。谢谢！
使用这种方法我们会遇到一些资源名称的问题，例如：Android JDK 版本。我们团队的一些成员对配置的 SDK 有不同的名称或不同的版本。将项目文件发送到 repo，您需要将这类事情与您的团队保持一致。直到昨天，我们还没有习惯将 proj 文件发送到 repo，但这变得很困难，因为我们的项目变得很大并且难以配置。
统一使用的SDK和相对路径是简单有效的解决方案
是的。现在我们所有的模块都指向“Project SDK”，我们与团队一起使用相同的 SDK。至少只是一处需要修改。但 IntelliJ 可以做得更好。

【解决方案6】：

我将 workspace.xml 带出源代码控制（+ 添加到 .gitignore）。

【讨论】：