我们团队中的每个人都使用IntelliJ IDEA,我们发现将其项目文件(.ipr和.iml)放入源代码管理中非常有用,这样我们就可以共享构建配置,设置和检查。此外,我们可以在TeamCity的持续集成服务器上使用这些检查设置。 (我们在.gitignore文件中有每用户工作区.iws文件,而不是源代码控制。)
但是,当您在IDEA中执行任何操作时,这些文件会以一些方式发生变化。 IDEA的问题数据库中存在一个问题(IDEA-64312),所以也许人们可能会认为这是IDEA中的一个错误,但在可预见的未来,这是我们需要忍受的错误。
直到最近,我们才使用Subversion,但最近我们转而使用Git。我们每个人都习惯了我们忽略的项目文件的更改列表,并且没有签入,除非我们想要与其他人共享项目文件更改。但是对于Git来说,真正的力量似乎是(从我们正在探索的)它所鼓励的连续分支,并且在分支之间切换是一个痛苦,项目文件总是被修改。通常它可以以某种方式合并更改,并尝试处理现在应用于新分支的项目文件更改。但是,如果新分支已更改项目文件(例如分支正在处理尚未在其他分支中的新模块),git只会抛出一个错误,即在文件中合并没有任何意义当分支都有变化并且你在本地有变化时,我宁愿理解它的观点。从命令行,可以在“git checkout”命令中使用“-f”强制它抛出本地更改并改为使用分支,但是(1)IDEA中的Git Checkout GUI命令(10.5.1)似乎没有那个我们可以找到的选项,所以我们需要定期切换到命令行,(2)我们不确定我们是否想养成使用它的习惯标志并告诉Git抛弃我们当地的变化。
所以,我们有一些关于我们必须处理的选项的想法:
我想我希望我们错过了一些明显的(或非显而易见的)解决方案,或许可以处理Git和IDEA似乎都具有的巨大可定制性。但似乎我们不可能成为唯一有这个问题的团队。 StackOverflow上类似的问题包括3495191,1000512和3873872,但我不知道它们是完全相同的问题,也许有人可以提出我概述的各种方法的利弊,这些问题的答案中列出的方法,或者他们推荐的方法。
谢谢。
答案 0 :(得分:46)
您可以使用IDEA的directory-based project structure,其中的设置存储在.idea目录而不是.ipr文件中。它比版本控制中存储的内容提供了更多fine-grained control。 .iml文件仍然存在,所以它不能解决它们中的随机变化(可能使它们不受源代码控制?),但是共享代码样式和检查配置文件之类的东西很容易,因为它们中的每个都是在.idea目录下的自己的文件中。
答案 1 :(得分:29)
来自官方DOC: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
答案 2 :(得分:23)
official answer is available。假设您正在使用现代(现在默认).idea
文件夹项目格式:
.idea/workspace.xml
(用户特定的).idea/tasks.xml
(用户特定的)此sample .gitignore file可能是一个有用的参考,但您仍应阅读上述链接,以了解这些条目出现的原因并确定您是否需要它们。
我个人也忽略了.idea/find.xml
文件,因为每次执行搜索操作时这似乎都会改变。
答案 3 :(得分:16)
我将workspace.xml从源代码控制中取出(+添加到.gitignore)。
答案 4 :(得分:10)
我们的团队不会检查路径特定的IntelliJ文件。我们假设人们知道如何使用IDE并设置项目。 IntelliJ文件进入“被忽略”的更改列表。
更新:
现在我正在使用Maven及其默认目录结构,答案更容易。
应要求IntelliJ忽略/.svn
,/.idea
和/target
个文件夹中的所有文件。与个人路径信息相关的所有内容都存储在/.idea
中。
其他一切都是公平的游戏,致力于Subversion或Git。
答案 5 :(得分:2)
只是为了分享我的团队使用的另一种方法:只需将任何与IDE相关的文件移动到IntelliJ无法识别的其他位置,并创建一个脚本以将其复制到所需的“活动”状态。 GIT忽略的位置。
此方法的好处是您可以选择通过版本控制共享IDE设置。唯一的缺点是您必须决定何时运行脚本(可能每个工作区克隆一次或需要更改时),并且您可以通过在构建过程或合并后钩子中合并脚本来自动执行此操作。
这种方法依赖于IntelliJ仅搜索特定位置的设置文件,因此它也适用于框架配置文件。实际上我们以同样的方式忽略了Grails .properties文件,因此开发人员不会意外地检查他们的本地配置更改。