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

How to deal with IntelliJ IDEA project files under Git source control constantly changing?

提问by

Everyone on our team uses IntelliJ IDEA, and we find it useful to put its project files (.ipr and .iml) into source control so that we can share build configurations, settings, and inspections. Plus, we can then use those inspection settingss on our continuous integration server with TeamCity. (We have the per-user workspace .iws file in the .gitignore file and not in source control.)

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

However, those files change in little ways when you do just about anything in IDEA. There's an issue in IDEA's issue database for it (IDEA-64312), so perhaps one might consider this a bug in IDEA, but it's one we'll need to live with for the foreseeable future.

但是，当您在 IDEA 中执行任何操作时，这些文件的变化很小。IDEA 的问题数据库中有一个问题 ( IDEA-64312)，所以也许有人可能认为这是 IDEA 中的一个错误，但在可预见的未来，我们需要忍受它。

Up until recently, we were using Subversion, but we recently switched to Git. We had each just gotten used to having a change list of project files that we ignored and didn't check in unless there were project file changes that we wanted to share with others. But with Git, the real power seems to be (from what we're exploring) the continuous branching that it encourages, and switching between branches is a pain with the project files always having been modified. Often it can just merge in the changes somehow, and tries to deal with the project file changes now being applied to the new branch. However, if the new branch has changed project files (such as the branch is working on a new module that isn't in the other branches yet), git just throws an error that it doesn't make any sense to merge in the files when both the branch has changes and you have changes locally, and I can rather understand its point. From the command line, one can use "-f" on the "git checkout" command to force it to throw out the local changes and use the branch's instead, but (1) the Git Checkout GUI command in IDEA (10.5.1) doesn't seem to have that as an option that we can find, so we'd need to switch to the command line on a regular basis, and (2) We're not sure we want to be in the habit of using that flag and telling Git to throw out our local changes.

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

So, here are some thoughts we have on options we have to deal with this:

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

1. Take the project files out of source control entirely. Put them in the .gitignore, and distribute them to each person and TeamCity via some other means, maybe by putting them in source control somewhere else or under other names. Our team's small enough this option is feasible enough to consider, but it doesn't seem great.
2. Continue living with it, trying to be sure to manage which files we have on which branches at a given time. As part of this, we might encourage each developer to have more than one copy of each project on their system, so they can have each checked out to a different branch with possibly different sets of project files.
3. Try having just the project (.ipr) in source control, with the module (.iml) files not in source control and in the .gitignore file. The main thing that seems to switch around on its own in the .ipr on a regular basis is the order of the shared build configurations, but maybe we can just share the information separately on how to set those up. I'm not quite sure how IDEA deals with this kind of thing of only having some of its files though, especially on a new checkout.

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

I guess I'm hoping there's some obvious (or non-obvious) solution we've missed, perhaps dealing with the huge customizability that Git and IDEA both seem to have. But it seems like we couldn't possibly be the only team having this problem. Questions that are kind of similar on StackOverflow include 3495191, 1000512, and 3873872, but I don't know as they're exactly the same issue, and maybe someone can come up with the pros and cons for the various approaches I've outlined, approaches listed in the answers to those questions, or approaches that they recommend.

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

Thank you.

谢谢你。

采纳答案by Esko Luontola

You can use IDEA's directory-based project structure, where the settings are stored in .idea directory instead of .ipr file. It gives more fine-grained controlover what is stored in version control. The .iml files will still be around, so it doesn't solve the random changes in them (maybe keep them out of source control?), but sharing things such as code style and inspection profiles is easy, since each of them will be in its own file under the .idea directory.

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

回答by Felipe

From official DOC: http://devnet.jetbrains.com/docs/DOC-1186

来自官方文档：http: //devnet.jetbrains.com/docs/DOC-1186

Depending on the IntelliJ IDEA project format (.ipr file based or .idea directory based), you should put the following IntelliJ IDEA project files under the version control:

.ipr file based format

Share the project .ipr file and and all the .iml module files, don't share the .iws file as it stores user specific settings.

.idea directory based format

Share all the files under .idea directory in the project root except the workspace.xml and tasks.xml files which store user specific settings, also share all the .iml module files.

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

基于 .ipr 文件的格式

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

基于 .idea 目录的格式

共享项目根目录下 .idea 目录下的所有文件，除了存储用户特定设置的 workspace.xml 和 tasks.xml 文件，还共享所有 .iml 模块文件。

I put it in my .gitignore:

我把它放在我的 .gitignore 中：

#Project
workspace.xml
tasks.xml

回答by Drew Noakes

An official answer is available. Assuming you're using the modern (and now default) .ideafolder project format:

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

• Add everything...
• Except .idea/workspace.xml(which is user-specific)
• Except .idea/tasks.xml(which is user-specific)
• Except some other files that might contain passwords/keys/etc (see above link for details)

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

This sample .gitignore filemight be a useful reference, though you should still read the above link to understand why these entries appear and decide if you need them.

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

Personally I also ignore the .idea/find.xmlfile as this seems to change every time you perform a search operation.

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

回答by ripper234

I took workspace.xml out of source control (+ added to .gitignore).

我将workspace.xml 脱离了源代码管理（+ 添加到.gitignore）。

回答by duffymo

Our team doesn't check in path-specific IntelliJ files. We assume that people know how to use the IDE and set up a project. IntelliJ files go into the 'ignored' change list.

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

UPDATE:

更新：

The answer is easier now that I'm using Maven and its default directory structure.

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

IntelliJ should be asked to ignore all files in /.svn, /.ideaand /targetfolders. Everything pertaining to an individual's path information is stored in /.idea.

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

Everything else is fair game to be committed to Subversion or Git.

其他一切都可以提交给 Subversion 或 Git。

回答by Shawn

Just to share another approach my team have used: Just move whatever IDE related files to a different location where IntelliJ doesn't recognize, and create a script to copy them to desired 'active' location that is ignored by GIT.

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

The benefit of this approach is that you kept the option of sharing IDE settings through version control. The only drawback is you have to decide when to run the script (probably once per workspace clone or when changes are desired), and you can automate this through incorporating the script in your build process or post-merge hook.

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

This approach relies on that IntelliJ searches only particular locations for its setting files, so it applies with framework configuration files also. Actually we ignored Grails .properties file the same way, so developers won't accidentally check-in their local configuration changes.

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