version-control - 合并 IntelliJ IDEA .IPR 和 .IWS 文件

Question

我们将 IntelliJ .IPR 和 .IWS 文件保存在我们的源代码控制中，但只要打开它们，它们就会不断被 IntelliJ 修改，即使没有对项目进行任何工作。

我们做错了什么？

Answer 1

"We keep our IntelliJ .IPR and .IWS files in our source control, but they keep getting modified by IntelliJ just by opening them, even without any work being done on the project."

.IWS 文件绝对是每个开发人员的文件，因此不应受源代码控制。

至于最近一个项目中的 .IPR 文件，我们最初尝试对这个文件进行版本化，在概念上接近它，就像使用 .Net 项目和 VS.Net .SLN 文件一样。我们的目标是在 15 分钟内让开发人员在干净的 PC 上启动并运行，其中包括安装 IDE 或本地数据库等依赖软件所需的时间。最后，我们接近了一些时间来调整本地配置，如下所示。

问题是 .IPR 文件存储的设置多于 .sln 文件 - 例如单个插件的设置。因此，覆盖的主要原因是如果具有不同插件配置的开发人员打开 IPR 文件，插件的一些默认设置将写入文件。我们认为开发人员不应该将自己限制在给定的插件超集(只是最低配置)。

我们缓解问题的方法(虽然没有完全解决)是切换到 .idea 文件夹格式。这将获取 .IPR 文件的内容并将许多节点拆分为 .idea 子文件夹中的单独文件和文件夹。从这里我们能够从源代码控制中排除许多经常写入文件的文件。我们排除的一些文件是:

工作区.xml

数据源.xml

sqlDataSources.xml

动态.xml

我们希望 IntelliJ 不理会的一些文件是(尽管责任也可能归咎于插件开发人员，而不仅仅是 Jetbrains):

projectCodeStyle.xml(因此我们可以在项目中获得一致的代码格式 - 同样可以根据开发人员的本地插件组合覆盖)。

runConfigurations 文件夹下的任何文件。配置运行配置可能非常耗时，特别是如果您有一个包含许多方面的复杂应用程序。只需打开 IDE 或构建即可更改的最常见愚蠢的事情是 RunnerSettings 下的“DEBUG_PORT”选项。我的观点是，如果它是动态分配的，为什么不具有“动态”值？

杂项.xml。该文件还包含插件配置。一些设置看起来很容易分享，而另一些则更适合个人配置。例如，IvyIDEA 插件为您的 ivy 配置文件放置了一个绝对路径。

模块文件。这些大部分都被单独留下，但一个不必要的覆盖示例是 IvyIDEA 插件将本地 ivy-cache 位置的详细信息放在此文件中。但这又是插件的错，而不是真正的 Jetbrains。

希望这可以帮助。

基督教。