はじめに
「プロジェクト管理ファイルについて」三部作の最後は、.idea
ディレクトリについてです。無駄に長いので、もうオススメ設定を公開しておきます。
リスト1 オススメのHOME>/.idea/.gitignoreの例
*.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 のような構成になっています。
図1 初期状態の.ideaディレクトリの例
この後、ライブラリを追加したり、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」だけ です。
図2 「 Preferences / Code Style」設定画面
「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
に保存されるので、そもそも共有できません。
図3 「 Preferences / Compiler / Gradle」設定画面
※「Offline mode」はAndroid Studio v0.4.0から追加されました。
コピーライト定義(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ツールウィンドウ」やエディタのタブに反映されます。
図4 「 Preferences / File Colors」設定画面
これもコードスタイルやCopyrightなどと同じく、設定内容を共有することができます(「 Shared colros」に設定したものに限る) 。カラー設定を一度でも共有すると設定ファイル .idea/fileColors.xml
が生成され、以後共有設定がひとつも無くなっても設定ファイルが消えることはありません。
なお「Shared colors」以外のカラー設定(Local colros)は、.idea/workspace.xml
に記録されます。
結論
そもそも「Shared Colors」を設定しないと、この設定ファイルはできません。逆説的ですが共有したいから「Shared colors」を設定したのでしょうから、当然このファイルはバージョン管理対象に置き共有すべきでしょう。個人的にファイルカラー設定をしてみたい程度であれば「Local colors」を使いましょう。
個別設定の管理方法と共有方法
コードスタイル、Copyright、ファイルカラーのように、いくつかの設定項目は設定のカタマリに名前を付けて保存することができます。この名前付き設定は、設定項目によって「スキーム」とか「プロファイル」とか呼ばれます(名称は統一されていません) 。
その情報の保存の仕方も設定項目によってマチマチで、コードスタイルのように「プロジェクト用には1種類だけ」とか、Copyrightのように「<プロファイル名>.xml
でそれぞれ保存」と節操がありません。
さらに楽しいことに「ファイルカラー」のように「複数のプロファイルを管理するが、明示的に共有する(Shared)かどうかを指定する」ものもあります。この場合「Sharedなプロファイル」しか.idea
ディレクトリに保存されません。
バラエティに富んでいて、ホント楽しいです……。
ファイルエンコードの設定(File Encodings)
.idea/encodings.xml
「Preferences / File Encodings」の設定が記録されています。設定画面を見ればイメージが沸くと思いますが、プロジェクトで使用するエンコードや、プロジェクト管理下のファイルのエンコードを指定します。
図5 「 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のバージョンによっては絶対パスで保存される場合があります。
図6 「 Preferences / Gradle」設定画面
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
として保存されます。
図7 「 Preferences / Inspections」設定画面
「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」で設定します。
図8 「 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と実体を関連付けします。企業内などのローカルネットワーク内やオンライン状態などインターネットに接続できない環境で利用する場合に便利です。ただし、そんなに一生懸命設定する項目でもありません。
図9 「 Preferences / Schemas and DTDs」設定画面
ひどいことに専用の設定ファイルを持ちません。「 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
に保存されます) 。
図10 「 Preferences / Scopes」設定画面
また、プロジェクトを作成した時点で.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
で記録されるので、個人用の辞書なのに、利用する環境によってファイル名が異なり使えない可能性がとても高いです。何を考えているんでしょうかね……。
図11 スペルチェックの辞書ファイルの実体
結論
共有するだけ無駄なのでバージョン管理対象にしなくてよいです。
ちなみに「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
に登録されます。
図12 「 Preferences / Tasks / Servers」設定画面
連携先以外の「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) 」によく似ています。
図13 「 Preferences / Template Data Languages」設定画面
結論
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倍マシです。
表1 設定箇所と保存先
設定箇所 保存先
Version Control ( 全般的な設定) .idea/vcs.xml
, .idea/workspace.xml
Version Control / Confirmation ( 確認項目) .idea/workspace.xml
Version Control / Background ( バックグラウンド処理) .idea/workspace.xml
Version Control / Ignored Files ( 除外ファイル) .idea/workspace.xml
Version Control / Issue Navigation ( チケット連携) .idea/vcs.xml
Version Control / Changelist Conflicts ( チェンジリストの衝突) .idea/workspace.xml
Version Control / GitHub <AS_CONFIG>/options/github_settings.xml
Version Control / CVS .idea/workspace.xml
Version Control / Git <AS_CONFIG>/options/vcs.xml
Version Control / Mercurial <AS_CONFIG>/options/vcs.xml
Version Control / Subversion .idea/workspace.xml
GitHubに二因子認証を設定している場合
「Preferences / Version Control / GitHub」で「Auth Type」を「Token」を選び、GitHubのアクセストークンを設定しておいてください。
図14 「 Preferences / Version Control / GitHub」設定画面
GitHubのアクセストークンはAuthorized Applications の「Personal Access Token」にある「Create new token」ボタンを押して発行できます。
図15 GitHubのアクセストークンの発行方法
結論
実のところ.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 にすばらしいエントリがあるので、まずはそちらを参考にしてください。
ここでは、タスク連携機能に関する注意点をいくつか紹介します。早めに断っておきますが、Android Studioのタスク連携はBTS/ITSのフロントエンドになりきるほどの機能はありません。Webブラウザの代わりに、ちょっとだけ素早くチケットを参照できる程度の機能だと思っておいて下さい。
タスク(チケット)の検索
"Open Task... "で連携先のBTS/ITSからチケットを検索しますが、大抵の連携先は「日本語のチケット名」で検索することができません。その代わり、チケットIDで検索することができます。この事を知っていると目的のチケットを探しやすいです。
図16 "Open Task..."によるタスク(チケット)の検索 - Githubの場合(クリックすると動きがわかります)
BTS/ITSのステータス連携
このタスク連携機能はチケットとAndroid Studioの作業(チェンジリストやコンテキスト)を紐付けるだけで、BTS/ITS側のステータスを操作するものではありません。
新しいチケットの作成/担当者の割り当て/チケットのステータス変更などの操作は、Android Studioから行うことはできません。"Open Task... "で検索できるチケットも「Preferences / Tasks / Servers」で設定したBTS/ITSのアカウントに紐付いたものだけです。
Bitbucketの課題トラッカーとの連携
連携には別途Bitbucketプラグイン が必要になります。プラグインのインストール方法は第31回 を参照してください。
Bitbucket連携の場合、"Open Task... "実行直後に(そのアカウントで参照可能な)すべてのチケットが一覧表示されます。このように連携先のBTS/ITSによって、コマンドの結果が若干変わります。
図17 "Open Task..."によるタスク(チケット)の検索 - Bitbucketの場合(クリックすると動きがわかります)
もうひとつのタスク連携
タスク連携機能が実装される前からあった、もうひとつのタスク連携について説明します。どのような機能かと言うと、コミットメッセージの特定のキーワードをBTS/ITSのチケットに紐付ける機能です。
この設定を行うことで、特定のキーワード(通常はチケットIDです)にリンクが付き、そこからBTS/ITSのチケット画面をWebブラウザに表示することができるようになります。
図18 Issue Navigationが設定済みの「Changesツールウィンドウ / Logタブ」
※チケットIDがリンクになっていて、クリックするとBTS/ITSのチケット画面が開く
このチケットの紐つけは「Preferences / Version Control / Issue Navigation」で行います。表2 と表3 はそれぞれGitHubとBitbucketの設定値です。
図19 「 Preferences / Version Control / Issue Navigation」設定画面
表2 GitHub issueの設定例
項目 値
Issue ID \w+\-(\d+)
Issue link https://github.com/<yourname>/<projectname>/issues/$1
Issue linkの例 https://github.com/masanobuimai/MyFirstAppProject/issues/$1
表3 Bitbucket課題トラッカーの設定例
項目 値
Issue ID #(\d+)
Issue link https://bitbucket.org/<yourname>/<projectname>/issue/$1
Issue linkの例 https://bitbucket.org/masanobuimai/myfirstappproject/issue/$1