Android studio - 整个 .idea 目录应该在 git ignore 中吗？

Android studio - should the entire .idea directory be in git ignore?

提问by dors

I saw a lot of examples for .gitignorefiles for AndroidStudio, some have .ideain them, and some don't.

我看到了很多AndroidStudio.gitignore文件示例，有些包含在其中，有些则没有。.idea

Is there a good reason not to add the entire .idea dir to .gitignore?

是否有充分的理由不将整个 .idea 目录添加到 .gitignore？

If it should not be completely ignored, are there specific files inside .idea (such as .iml) that should be in .gitignore?

如果不应该完全忽略它，那么 .idea 中是否有特定的文件（例如 .iml）应该在 .gitignore 中？

回答by mithrop

You can take a look at this page :

你可以看看这个页面：

IntelliJ doc about project configuration files

IntelliJ 文档关于项目配置文件

In the "Directory-based format", a particular line is interesting :

在“基于目录的格式”中，有一行很有趣：

The .idea directory contains a set of configuration files (.xml). Each file contains only a portion of configuration data pertaining to a certain functional area which is reflected in the name of a file, for example, compiler.xml, encodings.xml, modules.xml.

Almost all of the files contain information core to the project itself, such as names and locations of its component modules, compiler settings, etc. Thus, these files may (and should) be kept under version control.

.idea 目录包含一组配置文件 (.xml)。每个文件包含仅与这反映在一个文件的名称的某些官能区域的配置数据的一部分，例如，compiler.xml，encodings.xml，modules.xml。

几乎所有文件都包含项目本身的核心信息，例如其组件模块的名称和位置、编译器设置等。因此，这些文件可以（并且应该）保持在版本控制之下。

However, I properly HATE to make project IDE-dependent (I am currently working on a project made with NetBeans and it hurts to use it with Eclipse which becomes the standard of my company).

但是，我非常讨厌使项目依赖于 IDE（我目前正在开发一个用 NetBeans 制作的项目，将它与成为我公司标准的 Eclipse 一起使用会很痛苦）。

So, to answer your question :

所以，回答你的问题：

1. If you do not usesomething like Maven or Gradle to manage dependencies and build : keep the directory under version control. This way, the correct configuration of the project and dependencies will be available for everyone. In the counterpart, all developers will have to set their environment exactly the same way that you define it in the config files.
2. If you do usesomething like Maven or Gradle : correctly configure these tools and do not keep the directory under version control. Actually, all the information contained inside config files should bestored in Maven/Gradle files. Then let your developers configure their IDE depending of their environment. This way, using Eclipse, IntelliJ, Linux, Windows ... will not be a problem anymore.

1. 如果您不使用Maven 或 Gradle 之类的东西来管理依赖项和构建：将目录置于版本控制之下。这样，每个人都可以使用正确的项目和依赖项配置。相反，所有开发人员都必须以与您在配置文件中定义的方式完全相同的方式来设置他们的环境。
2. 如果您确实使用了 Maven 或 Gradle 之类的工具：请正确配置这些工具并且不要将目录置于版本控制之下。实际上，配置文件中包含的所有信息都应该存储在 Maven/Gradle 文件中。然后让您的开发人员根据他们的环境配置他们的 IDE。这样，使用 Eclipse、IntelliJ、Linux、Windows ……将不再是问题。

回答by JBaruch

OK, so after some "Yes" and "No" answers, I am adding a "Yes and no" answer :)

好的，所以在回答“是”和“否”之后，我添加了“是和否”的答案:)

The problem is that .ideais used for both project build configuration (dependencies declaration) and project settings (inspections, etc.).

问题在于它.idea用于项目构建配置（依赖项声明）和项目设置（检查等）。

You definitely don't want to use your IDE for your build configuration, but you might want to share the settings among the team. That's why you need to ignore only a part of the .ideacontent (like the librariesfolder and the modules.xmlfile), but keep others in the version control (e.g. the copyright, dictionariesand inspectionProfilesfolders and files under .idealike dynamic.xml, codeStyleSettings.xml, etc.).

您绝对不想将 IDE 用于构建配置，但您可能希望在团队之间共享设置。这就是为什么你只需要忽略的部分.idea内容（如libraries文件夹和modules.xml文件），但保留其他版本控制（例如copyright，dictionaries和inspectionProfiles下文件夹和文件.idea一样dynamic.xml，codeStyleSettings.xml等）。

回答by Jesse Greathouse

The concept of keeping the project configuration in VC is valid. I did this with my team because all of our developers happened to use PHPStorm for our projects and so it made sense to keep a common configuration ... in concept. We wanted to use the same dictionary files, the same coding standard rules, and the same plugin configurations.

在 VC 中保留项目配置的概念是有效的。我和我的团队一起这样做是因为我们所有的开发人员碰巧在我们的项目中使用 PHPStorm，因此在概念上保持通用配置是有意义的。我们希望使用相同的字典文件、相同的编码标准规则和相同的插件配置。

The reason why I qualify this with "in concept" is because there were issues with JetBrains' .idea folder that led to us not being able to use it. These were probably issues that could have been avoided or fixed, but it was unclear to us how to do it right, and we think that's a fault of JetBrains because as developers we do not have time nor desire to search for solutions on how to make our IDE work correctly.

我之所以用“概念上”来限定它，是因为 JetBrains 的 .idea 文件夹存在问题，导致我们无法使用它。这些可能是可以避免或修复的问题，但我们不清楚如何正确地做到这一点，我们认为这是 JetBrains 的错，因为作为开发人员，我们没有时间也不想寻找如何制作的解决方案我们的 IDE 工作正常。

That being said, the issues were had are the following:

话虽如此，但问题如下：

• Symlinking project folders doesn't work right. When I set up my projects, I symlink them into my home directory. What we discovered was that the project was set-up to use the exact symlink rather than just treating it like a concrete directory. This means that if another developer keeps his project in a different place, or simply does not use symlinks, the entire directory will be missing from the project navigator because it is quite literally looking for the symlink. What's worse is that I could never find this path value in the configuration. We were unable to find the exact config in the files constituting our .idea folder.
• Definition files are partitioned to users by default. This means if I want to add a word to my dictionary, it will be listed as a definition for me, jgreathouse, but other users will have their own definition section. The flagged words will still show up as a spelling mistake for other users. This is not desireable. The reason I add it to my definition file is because the IDE is wrong. I want these definitions to be intuitively shared with other users.
• Colleagues kept overwriting the configurations because their IDE would overwrite the configurations with their config currently in Memory. What I mean is that, a developer would be working, and merge their repository from origin, which would contain a project configuration change, instead of their IDE changing configurations, or even giving them a choice, it would automatically overwrite the .idea configuration with the current in-memory configuration of their IDE. In my opinion this makes the .idea configuration unusable as a shared configuration. In order to work around this, the developer would literally have to shut down that instance of their IDE, pull the repo, and re-open their IDE. It makes no sense to keep a shared configuration if the IDE instantly overwrites it with the configuration currently in memory. It's like not having a shared configuration at all.

• 符号链接项目文件夹不起作用。当我设置我的项目时，我将它们符号链接到我的主目录中。我们发现该项目被设置为使用确切的符号链接，而不仅仅是将其视为一个具体的目录。这意味着如果另一个开发人员将他的项目保存在不同的地方，或者只是不使用符号链接，整个目录将从项目导航器中丢失，因为它实际上是在寻找符号链接。更糟糕的是，我在配置中永远找不到这个路径值。我们无法在构成我们的 .idea 文件夹的文件中找到确切的配置。
• 默认情况下，定义文件分区给用户。这意味着如果我想在我的字典中添加一个词，它将作为我 jgreathouse 的定义列出，但其他用户将有自己的定义部分。被标记的单词仍会显示为其他用户的拼写错误。这是不可取的。我将它添加到我的定义文件的原因是因为 IDE 是错误的。我希望这些定义能够直观地与其他用户共享。
• 同事一直在覆盖配置，因为他们的 IDE 会用他们当前在内存中的配置覆盖配置。我的意思是，开发人员将工作，并从源合并他们的存储库，这将包含项目配置更改，而不是他们的 IDE 更改配置，甚至给他们一个选择，它会自动覆盖 .idea 配置IDE 的当前内存配置。在我看来，这使得 .idea 配置无法用作共享配置。为了解决这个问题，开发人员实际上必须关闭他们的 IDE 实例，拉出存储库，然后重新打开他们的 IDE。如果 IDE 立即用当前内存中的配置覆盖它，则保留共享配置是没有意义的。它'

I've done these types of shared IDE configurations in VC before with Visual Studio and Netbeans and it was always fine; but with .idea it feels simply unusable which is disappointing. I wish JetBrains would get on top of it and make it a better user experience.

我之前在 VC 中使用 Visual Studio 和 Netbeans 完成了这些类型的共享 IDE 配置，并且总是很好；但是使用 .idea 感觉根本无法使用，这令人失望。我希望 JetBrains 能够超越它并使其成为更好的用户体验。