はじめに

「プロジェクト管理ファイルについて」三部作の最後は、.ideaディレクトリについてです。無駄に長いので、もうオススメ設定を公開しておきます。

*.xml

!/codeStyleSettings.xml
!/copyright/*.xml
!/fileColors.xml
!/encodings.xml
!/gradle.xml
!/runConfigurations/*.xml

!/inspectionProfiles/*.xml
/inspectionProfiles/profiles_settings.xml

!/scopes/*.xml
/scopes/scope_settings.xml

!/templateLanguages.xml
!/vcs.xml

なぜ、こうしたかは本編のお楽しみです。

プロジェクト管理ファイル（.ideaの中身）

プロジェクト作成ウィザードに従って標準的な構成でプロジェクトを作成したときの.ideaディレクトリは図1のような構成になっています。

この後、ライブラリを追加したり、Preferencesで「Project Settings」の項目を変更することで、いくつかの設定ファイルが追加されていきます。

.idea/workspace.xml とはナニモノ？

.idea/workspace.xml

プロジェクト付属の.gitignoreにもはじめから除外ファイルとして設定されている .idea/workspace.xml にはAndroid Studioの今の状態（コンテキスト）が保存されます。

具体的には、以下のような内容です。

• エディタで開いているファイルの一覧や、タブの並び順など
  • 「今まで開いたファイルの一覧（"Recent Files"⁠）⁠」なども含む
• それぞれのツールウィンドウのオプションやツールウィンドウが保有する情報
  • 「Projectツールウィンドウ」のオプション
  • 「Favoritesツールウィンドウ」の「お気に入りリスト」や「ブックマーク」
  • デバッガのブレイクポイント、などなど
• Android Studioのレイアウト
  • エディタのレイアウトやカーソル位置
  • ツールウィンドウの並び順、開いている／閉じてる、などなど

Android Studioを使えば必ず更新される設定ファイルです。ばっちり個々人の環境に依存した内容を保存するので、バージョン管理システムの管理対象にしても仕方がありません（そんなことしたらコンフリクト発生しまくりです⁠）⁠。

ただし、個人が異なる環境で作業を継続する場合は、このファイルを共有したくなるときはあります。たとえば、ツールウィンドウのオプションは環境が変わるたびに設定し直さなければならず、ちょっと面倒なのです。

コードスタイルの設定（Code Style）

.idea/codeStyleSettings.xml

本連載ではまだ紹介していませんが、ソースコードを整形するコードスタイルに関する設定が保存されています。コードスタイルの機能そのものについては、いずれ紹介します。

設定は「Preferences / Code Style」で行います。コードスタイルは、スキーム（Scheme）と呼ぶ設定のセットを複数を持てるのですが、管理が独特で、プロジェクトで共有できるスキームは「Project」だけ です。

「Project」以外のコードスタイル設定は、<AS_CONFIG>/codestyles/に<スキーム名>.xmlで保存されます。

結論

プロジェクトでコードスタイルを共有したいのであれば、このファイルはバージョン管理対象にすべきです。難点を言えば「現在使用しているコードスタイル（のスキーム名⁠）⁠」も同じファイルに記録されているため「ちょっと個人用のスタイルに変えてみよう」などと気の利いたことをすると、途端にファイルが更新され、コミット候補にあがってしまいます。

このヘンな仕組みをわかった上で共有しておかないと、ちょっと大変なことになると思います。いずれコードフォーマッタについて紹介するので、それまでは「⁠（⁠スキームの）"Project"は絶対にいじるな！」と思っていれば十分です。

コンパイラの設定（Compiler）

.idea/compiler.xml

(.idea/groovyc.xml, .idea/androidDexCompiler.xml, idea/workspace.xml)

「Preferences / Compiler」以下の設定内容が記録されています。ひどいことに、ここの設定がすべて記録されるわけではありません。大半は .idea/workspace.xml に記録されます。確認した範囲では、.idea/compiler.xmlに保存される設定は以下の通りでした。

• 「Compiler」の「Resource patterns」の内容。
• 「Compiler / Excludes」のすべての内容。
• 「Compiler / Java Compiler」のすべての内容。
• 「Compiler / RMI Compiler」のすべての内容。

それ以外の項目については、以下の通りです。

• 「Compiler」の「Resource patterns」以外の項目は .idea/workspace.xml に記録される。
• 「Compiler / Groovy Compiler」の内容は .idea/groovyc.xml に記録される。
• 「Compiler / Gradle」の内容は、.idea/gradle.xmlと.idea/workspace.xml に記録される。
• 「Compiler / Android Compilers」の内容は、.idea/androidDexCompiler.xml に記録される。
  • ここにはDEX CompilerやProGuardの設定が含まれていて非常に気になるのですが、実際にビルドしてみても、ここの設定が影響している様子はうかがえませんでした。IntelliJの名残りで残っているだけなのでしょう。

結論

Android Studioのビルドシステムは、Gradleが行っているので「Preferences / Compiler」の設定そのものがそれほど意味を持ちません。よって共有する必要は無いでしょう。

Gradleのオプション設定（⁠「⁠Preferences / Compiler / Gradle⁠」⁠）は、主に.idea/gradle.xmlに保存されるので、.idea/compiler.xmlを共有しても意味は無いです。ちなみに図3の3つの設定は、.idea/workspace.xmlに保存されるので、そもそも共有できません。

コピーライト定義（Copyright）

.idea/copyright/profiles_settings.xml, idea/copyright/<プロファイル名>.xml

第12回で紹介したCopyrightに関する設定が保存されます。設定画面は「Preferences / Copyright」です。

profiles_settings.xmlには現在使用している Copyright のプロファイル名が記録され、個別のCopyrightプロファイルは、このディレクトリに <プロファイル名>.xml で保存されます。当然ですが、Copryrightのプロファイルを削除すれば、ここの設定ファイルも消えて無くなります（profiles_settings.xmlはずっと残ります⁠）⁠。

結論

Copyright機能を使うのであれば、このディレクトリ配下はバージョン管理して共有しましょう。その場合、Copyrightプロファイルは各自が勝手に変更せず、だれか代表者にメンテナンスを任せた方がよいでしょう（個人的にたしなむ程度ならムリに共有する必要もありませんが⁠）⁠。

現在使用している Copyrightプロファイルを記録している .idea/copyright/profiles_settings.xmlも共有すべきでしょう。Copyrightを統一したいためにこの機能を使っているのに、個人個人でそのプロファイルが異なったら本末転倒です（意図的に変えたい用事があるならば、話は別です⁠）⁠。

Copryright機能を使わないのであれば、バージョン管理する必要はありません。むしろ、Copryrightプラグインそのものを無効にしてもよいでしょう。Copyrightプラグインが無効なら、そもそも設定ファイルは作成されません。

ファイルカラーの設定（File Colors）

.idea/fileColors.xml

これもまだ紹介したことが無い機能ですが、Android Studioは特定のスコープ（Scope）に対して色づけをすることができます。このカラー設定は「Projectツールウィンドウ」やエディタのタブに反映されます。

これもコードスタイルやCopyrightなどと同じく、設定内容を共有することができます（⁠「⁠Shared colros」に設定したものに限る⁠）⁠。カラー設定を一度でも共有すると設定ファイル .idea/fileColors.xml が生成され、以後共有設定がひとつも無くなっても設定ファイルが消えることはありません。

なお「Shared colors」以外のカラー設定（Local colros）は、.idea/workspace.xml に記録されます。

結論

そもそも「Shared Colors」を設定しないと、この設定ファイルはできません。逆説的ですが共有したいから「Shared colors」を設定したのでしょうから、当然このファイルはバージョン管理対象に置き共有すべきでしょう。個人的にファイルカラー設定をしてみたい程度であれば「Local colors」を使いましょう。

ファイルエンコードの設定（File Encodings）

.idea/encodings.xml

「Preferences / File Encodings」の設定が記録されています。設定画面を見ればイメージが沸くと思いますが、プロジェクトで使用するエンコードや、プロジェクト管理下のファイルのエンコードを指定します。

ビルドシステムを自前で持っているIntelliJの場合は、この画面の「IDE Encoding」がコンパイラに渡すファイルエンコードになるのですが、Android Studioの場合、Gradleでビルドするためこの設定はあまり意味を持ちません。Gradleへのエンコード指定は第6回で紹介したようにbuild.gradleに指定します。

「Project Encoding」はAndroid Studioからファイルを作成したときの、初期状態のエンコードになります。

結論

コンパイラに対しての影響力はありませんが、新規作成するファイルの初期エンコードに影響があるので、異なるプラットフォームが混在している環境で開発する場合は、このファイルは共有しておいたほうが無難です。

使用するバージョン管理システムによっては意味がない事もあるし、同じプラットフォームしかない／ひとりでしか開発してない、などの場合は共有するまでもないですが、設定ファイルもひとつだけなのでケチらず共有しておきましょう。

Gantの設定（Gant）

.idea/gant_config.xml

「Preferences / Gant」の設定内容を記録します。ちなみにGantとはGroovy製のビルドツールのひとつです。

結論

IntelliJの名残で設定項目が残っているだけで、Android Studioでは全く意味を成しません。当然、バージョン管理対象外です。これも設定しないかぎり設定ファイルは生成されないので、無視しておきましょう。

Gradleの設定（Gradle）

.idea/gradle.xml

「Preferences / Gradle」の設定と「Preferences / Compiler / Gradle」の設定が記録されます。

前回も説明しましたが、「⁠Preferences / Gradle」の「Linked Gradle projects」部分がAndroid Studioのバージョンによっては絶対パスで保存される場合があります。

IntelliJ IDEAで同ファイルを確認すると、絶対パスではなく $PROJECT_DIR$ という変数が設定されているので、単なるバグだと思います。実際、この箇所を $PROJECT_DIR$ に書き直しても問題なく動きます（Android Studio v0.3.6, v0.3.7、v0.4.0のWindows版で確認⁠）⁠。いずれ解消すると思いますが、一応気にするようにしてください。

結論

.idea/gradle.xmlがAndroid Studioに対して「このディレクトリがAndroid Studioのプロジェクトである」ことをたらしめているので、必ず共有しましょう。

インスペクションのプロファイル設定（Inspections）

.idea/inspectionProfiles/<プロファイル名>.xml

（<AS_CONFIG>/inspection/<プロファイル名>.xml）

第14回で紹介したコード検査機能の設定が保存されます「Preferences / Inspections」で作成したプロファイルのうち「Share profile」がONになったものだけが、.idea/inspectionProfilesディレクトリに<プロファイル名>.xmlとして保存されます。

「Share profile」がONになっているプロファイルがひとつも無いと、この設定ディレクトリそのものが消えて無くなります。ちなみに「Share profile」がOFFの場合、設定情報は <AS_CONFIG>/inspection/ ディレクトリに保存されます（ファイル名は <プロファイル名>.xmlです⁠）⁠。

結論

プロジェクトでインスペクションの設定を共有するのであれば、ここはバージョン管理対象にするべきです。当然ながら共有するプロファイル名、それをメンテナンスするルールなどを定めておいた方がよいでしょう。無難な設定は「Project Default」プロファイルを共有（Share profileをON）することだと思います。

なお.idea/inspectionProfiles/profile_settings.xmlには「現在使っているプロファイル」が保存されます。「⁠プロファイルは共有するが、カレントの設定は個人の裁量に任せる」のであれば、このファイルは共有しないほうがよいでしょう。

ランゲージインジェクションの設定（Language Injections）

<AS_CONFIG>/options/IntelliLang.xml

第13回でちらっと紹介した「Language Injection」に関する設定です。「⁠Preferences / Language Injections」で設定します。

結論

この設定は「Project Settings」にあるにもかかわらず、<AS_CONFIG>/options/IntelliLang.xmlに保存されます。そのため共有するとかしないとか、そもそも関係ありません。

ちょっとズルい気もしますが、他にもそんな設定項目があります。

Mavenの設定（Maven）

.idea/workspace.xml

「Preferences / Maven」の設定です。ちなみにMavenとはJava製のビルドツールのひとつです。

「Gant同様、IntelliJの名残で設定項目が残っているだけで全く意味を成さないのでは？」と思っていたのですが、Android StudioでGoogle App Engineのバックエンドサービスを作成するとMavenプロジェクトとして作られます（メニューバーの「Tools → Google Cloud Tools → Generate App Engine Backend⁠」⁠）⁠。このあたりを見ると、たまたま残しているのではなく意図的に残しているのかも知れませんね。

結論

Android StudioにMavenサポートが必要かどうかは別として、そもそも専用の設定ファイルはできず、すべて .idea/workspace.xml に保存されます。仮にMavenを使ったモジュールがあったとしても、Mavenの設定を共用する方法はありません。

pom.xmlさえあれば十分という発想なのでしょうか、Gradleの設定ファイルとはずいぶん扱いが異なります。

スキーマやDTDの設定（Schemas and DTDs）

.idea/misc.xml, <AS_CONFIG>/options/other.xml

XML文書で用いるXMLスキーマやDTDに対してURIと実体を関連付けします。企業内などのローカルネットワーク内やオンライン状態などインターネットに接続できない環境で利用する場合に便利です。ただし、そんなに一生懸命設定する項目でもありません。

ひどいことに専用の設定ファイルを持ちません。「⁠External Schemas and DTDs」や「Default HTML language level」は .idea/misc.xml に保存されますが、それ以外はすべて <AS_CONFIG>/options/other.xmlに保存されます。

結論

「Ignored Schemas and DTDs」や「XML Catalog」は「IDE Settings」に属する設定項目なので対象外です。それ以外の項目ですが、前回保留にしていた.idea/misc.xmlに保存されます。この設定ファイル、なんだかよく分類できていない情報が保存されている事がわかったので、もう共有対象から除外してしまいましょう。

スコープの設定（Scopes）

.idea/scopes/scope_settings.xml, .idea/scopes/<スコープ名>.xml

第8回でちらっと紹介した「Scopes」に関する設定を保存しています。「⁠Preferences / Scopes」でスコープを定義しますが、これもCopyrightやインスペクションと同じく共有するかどうかの設定（Share scope）を持ちます。「⁠Share scope」なスコープを作ると、<スコープ名>.xmlというファイルがここにできあがります（⁠「⁠Local」なスコープは.idea/workspace.xmlに保存されます⁠）⁠。

また、プロジェクトを作成した時点で.idea/scopes/scope_settings.xmlという設定ファイルができあがっていますが、こちらはメニューバーの「Analayze」にある各種依存性分析（"Analayze ～ Dependencies"）のオプションが記録されています。

結論

Copyrightやファイルエンコード、ファイルカラーなどスコープに依存した設定項目があります。これらの設定で独自定義したスコープを利用しているのであれば、スコープ定義も共有しておく必要があります。というより、共有したいスコープ（Shared scope）を作らない限り、設定ファイルはできあがらないので「共有したいから作った」とも言えるでしょう。

ただし、初めからある .idea/scopes/scope_settings.xml はスコープ定義とは用途が異なる設定ファイルで、共有するより個々人の好みの設定を持つほうが適切と思いますので、こちらは共有しないことをオススメします（たぶん、共有していても邪魔になります⁠）⁠。

スペルチェック用の辞書（Spelling）

.idea/dictionaries/<ログインアカウント名>.xml

初期状態ではディレクトリすら存在していません。スペルチェックでtypoを指摘された時に辞書登録したか「Preferences / Spelling」の「Accepted Words」に登録した単語が記録されます。しかも、厄介な事に <ログインアカウント名>.xml で記録されるので、個人用の辞書なのに、利用する環境によってファイル名が異なり使えない可能性がとても高いです。何を考えているんでしょうかね……。

結論

共有するだけ無駄なのでバージョン管理対象にしなくてよいです。

ちなみに「Preferences / Spelling」設定画面の「Dictionaries」タブに指定するのは「辞書ファイル（*.dic）があるディレクトリ」で、その情報は .idea/workspace.xmlに保存されます。*.dicファイルの中味は1行に1単語が羅列されたテキストファイルです。

どうやら、スペルチェックはあくまで個人のたしなみというのが、Android Studioのコンセプトのようです。

タスク管理の設定（Tasks）

.idea/misc.xml

（.idea/workspace.xml, <AS_CONFIG>/tasks/<プロジェクト名>.zip）

GitHubやBitbucketの紹介のときに「あとで解説する」としていた課題追跡システム（Bugs/Issues Tracking System：BTS/ITS）と連携するための設定です。

「Preferences / Tasks / Servers」には連携先のBTS/ITSを設定します。連携先ごとに共有設定（Share URL）を行うことができ、共有（Share URLがON）の場合、その連携先の情報は.idea/misc.xmlに登録されます。

連携先以外の「Preferences / Tasks」の設定内容は.idea/workspace.xmlに記録されます。

タスク管理がどういうものかは今回の番外編で紹介します。設定ファイルの保存先という観点では、BTS/ITSから連携したタスク（チケット）などは、<AS_CONFIG>/tasksにzipファイルとして保存されます。

結論

個人的には積極的に共有を勧めたくない .idea/misc.xml に共有したいBTS/ITSの情報が記録されます。疑問があるとすると、BTS/ITSの接続情報とはアカウント情報（IDやパスワード）の事で、個人固有ではなくプロジェクト共有のアカウントでBTS/ITSを運用するケースが思いつきづらいという事です。

なので、結論は変わらず「.idea/misc.xml は共有しない」とします。連携情報以外の設定は、.ideaディレクトリに共有できる状態で保存されないため、共有対象になりえません。

テンプレート言語の設定（Template Data Languages）

.idea/templateLanguages.xml

FreeMarkerやVelocityといったテンプレート言語の対象言語を指定します。「⁠Preferences / Template Data Languages」で設定しますが、設定の仕方は前述した「ファイルエンコードの指定（File Encodings⁠）⁠」によく似ています。

結論

Android開発で、FreeMarkerやVelocityなどのテンプレートエンジンを使う機会があるのかよくわかりませんが、対象ファイルはひとつだけで邪魔になるわけでもない、という消極的理由ですが、せっかくなので共有しておきましょう。

ターミナルの設定（Terminal）

<AS_CONFIG>/options/terminal.xml

Android Studio v0.3.6あたりから追加された「Terminalツールウィンドウ」に関する設定です。

結論

設定ファイルのパスを見ればわかるとおり、これも「Project Settings」にみせかけて実は「IDE Settings」です。つまり、これも共有対象になり得ません。

バージョン管理の設定（Version Control）

.idea/vcs.xml, .idea/workspace.xml, <AS_CONFIG>/options.github_settings.xml, <AS_CONFIG>/options/vcs.xml

バージョン管理システムとの連携情報です。設定箇所も多数ありますが、実のところほとんどが「IDE Settings」であったり.idea/workspace.xmlに記録される個別設定です。どの設定がどこに保存されるのか 表1にまとめましたが、みごとに節操がありません。意外だったのが「除外ファイル設定（Preferences / Version Control / Ignored Files⁠）⁠」が、.idea/workspace.xmlに保存されることです。これならば、Android Studioの除外ファイル設定は使わず、.gitignoreや.hgignoreを使った方が4096倍マシです。

結論

実のところ.idea/vcs.xmlくらいしか共有する対象がありません。

Android Studioは同ファイルが無くても、バージョン管理システムからチェックアウトしてマウントした時点で再作成します。そうでなくても、プロジェクトディレクトリが何かしらのバージョン管理システムの管理下にあれば、それを自動的に認識して.idea/vcs.xmlを再生成します。

よって必ずしも共有しなければならない類のファイルではありませんが、積極的に除外する理由もないので共有しておきましょう。

全体のまとめ

「こんなマニアックな話題を3回を続けてしまって良いのだろうか？」と自問することもありましたが、このあたりがスッキリしないとチーム開発で悶々して効率的なコーディングは出来ないな、と開き直ることにしました。

.ideaディレクトリの管理する／しないファイルの選定は複雑で、.gitignoreのホワイトリストを使って例示しましたが、除外ファイル指定にホワイトリスト方式を使えないバージョン管理システムの場合、さらに指定が大変です。ある程度は割り切って人間系で管理することも考えておいた方が良いでしょう（いわゆる「運用で回避」ってやつです⁠）⁠。

なお、中編・後編で紹介した.ideaディレクトリの設定ファイル群は、素のAndroid Studioが生成するファイルだけです（v0.3.6～v0.4.0で確認⁠）⁠。今後のバージョンアップや追加したプラグインによって、この設定ファイルは多少増減すると思います。だいたいはファイル名からどの設定項目に該当する設定ファイルか類推できますし、それほど重要な設定ファイルが登場するとも考えづらいので、そう身構える必要はないでしょう。

番外編：タスク連携ってなに？

一見すると独立した機能のように思えますが、対象のプロジェクトが何かしらのバージョン管理システムと連携している状態ではないと利用できません。

タスク連携機能は、課題管理システム（BTS/ITS）のチケット（タスク）とチェンジリストを紐付ける機能です。EclipseのMylynに相当する機能ですが、Mylynほど高機能ではありません。基本的にチケットは参照専用です。

タスクはチェンジリストに紐付くだけではなく、タスクごとに専用の状態（コンテキスト）を持ちます。コンテキストとはIDEの状態―――どのファイルを開いていた、どのツールウィンドウを使っていたなど、イメージとしてはタスクごとに .idea/workspace.xml を切り替えられるようになると思って下さい。

タスクの連携先となるBTS/ITSの設定は「Preferences / Tasks」で行います。主要なBTS/ITSは大抵サポートしており、Git編（第27回）、Mercurial編（第31回）でかるく紹介したGitHub Issues、Bitbucketの課題トラッカーもサポートしています。

タスク連携の注意点

使い方については、IntelliJ Advent Calendar 2013にすばらしいエントリがあるので、まずはそちらを参考にしてください。

• IntelliJのTasks機能とGitHubのIssuesを連携させてチケット駆動開発
  • @radiocatzさん、ありがとうございます。

ここでは、タスク連携機能に関する注意点をいくつか紹介します。早めに断っておきますが、Android Studioのタスク連携はBTS/ITSのフロントエンドになりきるほどの機能はありません。Webブラウザの代わりに、ちょっとだけ素早くチケットを参照できる程度の機能だと思っておいて下さい。

タスク（チケット）の検索

"Open Task..."で連携先のBTS/ITSからチケットを検索しますが、大抵の連携先は「日本語のチケット名」で検索することができません。その代わり、チケットIDで検索することができます。この事を知っていると目的のチケットを探しやすいです。

（チケット）の検索 - Githubの場合` &title=`図16　"Open Task..."によるタスク（チケット）の検索 - Githubの場合` &width=`400` />

BTS/ITSのステータス連携

このタスク連携機能はチケットとAndroid Studioの作業（チェンジリストやコンテキスト）を紐付けるだけで、BTS/ITS側のステータスを操作するものではありません。

新しいチケットの作成／担当者の割り当て／チケットのステータス変更などの操作は、Android Studioから行うことはできません。"Open Task..."で検索できるチケットも「Preferences / Tasks / Servers」で設定したBTS/ITSのアカウントに紐付いたものだけです。

Bitbucketの課題トラッカーとの連携

連携には別途Bitbucketプラグインが必要になります。プラグインのインストール方法は第31回を参照してください。

Bitbucket連携の場合、"Open Task..."実行直後に（そのアカウントで参照可能な）すべてのチケットが一覧表示されます。このように連携先のBTS/ITSによって、コマンドの結果が若干変わります。

（チケット）の検索 - Bitbucketの場合` &title=`図17　"Open Task..."によるタスク（チケット）の検索 - Bitbucketの場合` &width=`400` />

もうひとつのタスク連携

タスク連携機能が実装される前からあった、もうひとつのタスク連携について説明します。どのような機能かと言うと、コミットメッセージの特定のキーワードをBTS/ITSのチケットに紐付ける機能です。

この設定を行うことで、特定のキーワード（通常はチケットIDです）にリンクが付き、そこからBTS/ITSのチケット画面をWebブラウザに表示することができるようになります。

このチケットの紐つけは「Preferences / Version Control / Issue Navigation」で行います。表2と表3はそれぞれGitHubとBitbucketの設定値です。