如何在Git源代码控制下处理IntelliJ IDEA项目文件不断变化？ [英] How to deal with IntelliJ IDEA project files under Git source control constantly changing?

问题描述

我们团队中的每个人都使用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. 尝试在源代码管理中使用项目（.ipr），并且模块（.iml）文件不在源代码管理和.gitignore文件中。似乎在.ipr中定期切换的主要内容是共享构建配置的顺序，但也许我们可以单独分享有关如何设置这些信息的信息。我不太清楚IDEA如何处理这种只有部分文件的情况，特别是在新的结帐时。

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

谢谢。

基于目录的项目结构，其中的设置存储在.idea目录中而不是.ipr文件中。它提供了更多细粒度控制，而不是版本控制中存储的内容。 .iml文件仍然存在，所以它不能解决它们中的随机变化（可能使它们远离源代码管理？），但共享代码样式和检查配置文件等内容很容易，因为它们中的每一个都将在它自己的.idea目录下的文件中。

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.)

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.

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.

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.

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.

Thank you.

解决方案

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 control over 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.

这篇关于如何在Git源代码控制下处理IntelliJ IDEA项目文件不断变化？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！