はじめに

Git，Subversion，Mercurialと個別のバージョン管理システムの話が一通り終わったので，今度からは共通の話をします。今回は「Android Studioのプロジェクト管理ファイルってバージョン管理したほうがいいの？」です。

中途半端に長くなったので前・中・後編の3回に分けて説明します。前編の今回は能書きばかりで肝心な話題は次回以降に持ち越しです。

その前に

今回のシリーズでよく登場するパスのシンボルについて再掲しておきます。より細かい内容が知りたい方は，Android Studioのプロジェクト構成は第5回を，Android Studioの設定ディレクトリは第2回を，それぞれ参照しておいてください。

Android Studioのプロジェクト概要

Android StudioもいっぱしのIDEなので，独自のプロジェクト管理ファイルを持ちます。具体的には，<PROJCET_HOME>/.ideaディレクトリにあるファイル群と，各種モジュール定義を行っている*.imlファイルです。これらはEclipseでいう.classpathや.projectに相当します。

Android Studioのプロジェクトウィザードから作成した典型的なプロジェクトの構成は図1の通りです。初期のAndroid Studioと比べるとプロジェクト名やモジュール名は若干変わりましたが，それ以外の構造は変わっていません。

このうち明らかにバージョン管理の対象にしなくてよいのは，ビルド成果物を含む<PROJCET_HOME>/<MODULE_HOME>/buildディレクトリ，Gradleのキャッシュディレクトリの<PROJCET_HOME>/.gradleディレクトリ，build.gradleが参照するローカル設定の<PROJCET_HOME>/local.propertiesファイルの3つです。

それ以外はバージョン管理対象にしてよいファイルやディレクトリなのですが，Android Studioのプロジェクト管理ファイル群の扱いがハッキリしません。

一応，プロジェクトに付属している .gitignoreファイルを参考にすると「<PROJCET_HOME>/.idea/workspace.xmlだけはバージョン管理しなくてよい」となりますが，果たして信じてよいのでしょうか……。

バージョン管理のポリシーあれこれ

プロジェクト管理ファイルの話に入る前に，そもそもこれらをバージョン管理する必要があるかどうかについて考えてみます。バックアップという観点では，プロジェクトに必要な情報なのでバージョン管理しておいたほうがよいですが，チーム開発という観点で見た場合，ホントウに全部管理しないとダメ？という疑問が出てきます。

バージョン管理のポリシーについても，その目的ごとに変わるので一概に「これが決定版」というものは出来ないでしょう。

ケース1. 個人で，かつ同じ環境で開発する場合

最も小さな構成のバージョン管理形態だと思います。要するにバージョン管理システムの役割は（履歴付きの）バックアップですね。

この場合，ビルド成果物以外はすべてバージョン管理対象にしても問題になることは無いでしょう。つまり，Android Studioが生成するプロジェクトに付いてきている .gitignore のままで良いです。

ケース2. 個人だけど，異なる環境で開発する場合

バージョン管理システムを扱うのは自分一人だけれど，チェックアウトする環境が複数ある場合です。たとえば自宅と職場といった具合です。異なるPCにチェックアウトしたとしても，それらの環境差違が無いような構成にしている場合は，ケース1となんらかわりません。ここでいう環境差違とは，インストールしているAndroid StudioやAndroid SDKのバージョンやインストール先，チェックアウトしたプロジェクトのディレクトリがまったく同じということを指します。

このケースの本質的な状況は，どちらかというと「職場はWindowsだけれど自宅はMac」のように，外的要因で環境差違を解消できないような状況を指します。筆者の状況がまさにこれになります。

この時点からAndroid Studioの管理ファイルをどうバージョン管理システムに登録するか悩み始めます（⁠「⁠異なる環境で利用したいけれど，IDEのセットアップに手間をかけたくない」ために悩む⁠）⁠。要するにプロジェクト付属の.gitignoreのまま共有すると，作業環境によって設定ファイルの更新が頻発します。

ケース3. チームで，皆がAndroid Studioを使って開発する場合

開発者が自分ひとりか，チームの複数人かの違いで，プラットフォーム（OS）やAndroid Studioバージョン，チェックアウト先をすべて統一するのであればケース1と条件は同じです。いわゆる「大規模開発」で良くやる手口なのですが，Android開発でもこのような手口は現実的なのでしょうか？

同一プラットフォームであっても，全員の環境をすべて統一するのはなかなか骨が折れる作業です。また ケース1 との決定的な違いは関係者が複数人居ることで，全員が同じくらいAndroid Studioに習熟しているとは限らないというのがポイントです。ただし，その解決策の提示は本連載の主旨とはズレるので，あえて触れません（習熟度が異なるため，環境差異を作らず全員統一環境にする，というのが答えと言えば答えです⁠）⁠。

この場合は「習熟度の異なる利用者が参加するので，セットアップはなるべく手間ヒマかからず，かつIDE（Android Studio）の機能を最大限活用したい」と考えるでしょう。

完全に作業環境を統一するのであればケース1と同じく，プロジェクト付属の .gitignore のままで十分ですが，Android SDKのインストール場所やプロジェクトのチェックアウト先くらい，個人の自由にさせて欲しいとなると ケース2 と似たような悩みを抱えます（利用者が複数人いるので，ケース2とはちょっと変わった悩みを抱えます⁠）⁠。

ケース4. チームで，おのおのが好きな環境で開発する場合

個人的にはチーム開発であろうと開発者個人の好みは尊重されるべきだと思うので，この形が理想だと思っています。だけれども。Android Studioが作成するGradleベースのプロジェクトをAndroid Studio以外で開発するのは現実的なのだろうか？とも思っています。

Android Studioへのマイグレーション方法を持っているEclipseでさえ，Android Studioとプロジェクトを共用するのは困難です。現実的にありえるケースとしては，以下の3パターンくらいでしょう。

• テキストエディタで開発して，ビルドにgradleを利用する。
• NetBeansのNBAndroidプラグインを使って，Android Studioのプロジェクトをマウントする。
• EclipseベースのプロジェクトをGradleエクスポートして，Android Studioでも開発できるようにする（Android Studio→EclipseはNGだけど，その逆は可能⁠）⁠。

Eclipseとの共用はそれなりに価値がありそうですが，それ以外はあえてそれを選択する良さがわかりかねます。この他にIntelliJ IDEAのCommunity版やUltimate版との共用が可能ですが，それってバリエーションのウチに入らないな，とも思います。

この場合はケース2，ケース3の延長線で「手間ヒマかけず，Android Studioのプロジェクトを共有したい」と考えるか，または「ビルド関連の情報はGradle（build.gradle）に集約されているので，IDE依存の管理ファイルを共有することはまかりならん」と考えるかも知れません。

前者の場合 ケース3と同じ悩みを抱え，後者の場合はバッサリと「Android Studioの設定ファイルは共有しない」と決めてしまいます（それがうまく行くのかは後述します⁠）⁠。