我们团队中的每个人都使用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,但我不知道它们是完全相同的问题,也许有人可以为我概述的各种方法提出利弊,这些问题的答案中列出的方法,或他们推荐的方法。
谢谢。
您可以使用IDEA的directory-based project structure,其中的设置存储在.idea目录而不是.ipr文件中。它为版本控制中存储的内容提供了更多的fine-grained control。 .iml文件仍然存在,所以它不能解决它们中的随机变化(可能使它们不受源代码控制?),但是共享代码样式和检查配置文件之类的东西很容易,因为它们中的每个都是在.idea目录下的自己的文件中。
来自官方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
一个official answer is available。假设您正在使用现代(现在默认).idea
文件夹项目格式:
.idea/workspace.xml
除外(用户特定).idea/tasks.xml
除外(用户特定)这个sample .gitignore file可能是一个有用的参考,但你仍然应该阅读上面的链接,以了解为什么这些条目出现并决定你是否需要它们。
我个人也忽略了.idea/find.xml
文件,因为每次执行搜索操作时这似乎都会改变。
我将workspace.xml从源代码控制中取出(+添加到.gitignore)。
我们的团队不会检查路径特定的IntelliJ文件。我们假设人们知道如何使用IDE并设置项目。 IntelliJ文件进入“忽略”更改列表。
更新:
现在,我正在使用Maven及其默认目录结构,答案更容易。
应该要求IntelliJ忽略/.svn
,/.idea
和/target
文件夹中的所有文件。与个人路径信息相关的所有内容都存储在/.idea
中。
其他一切都是公平的游戏,致力于Subversion或Git。
只是为了分享我的团队使用的另一种方法:只需将任何IDE相关文件移动到IntelliJ无法识别的其他位置,并创建一个脚本将其复制到GIT忽略的所需“活动”位置。
这种方法的好处是您可以选择通过版本控制共享IDE设置。唯一的缺点是您必须决定何时运行脚本(可能每个工作区克隆一次或需要更改时),并且您可以通过在构建过程或合并后钩子中合并脚本来自动执行此操作。
此方法依赖于IntelliJ仅搜索特定位置的设置文件,因此它也适用于框架配置文件。实际上我们以相同的方式忽略了Grails .properties文件,因此开发人员不会意外地签入他们的本地配置更改。