はじめに
Git,
中途半端に長くなったので前・
※除外ファイルの説明に都合が良いので.gitignore
を例に用いて説明していきます。
その前に
今回のシリーズでよく登場するパスのシンボルについて再掲しておきます。より細かい内容が知りたい方は,
表1 文中に登場するシンボルの意味
シンボル | 意味 |
---|---|
<PROJCET_ | Android Studioのプロジェクトのトップディレクトリ |
<MODULE_ | プロジェクト内に作成したモジュールのトップディレクトリ |
<AS_ | Android Studioの設定ディレクトリ |
<HOME> | 利用者のホームディレクトリ |
Android Studioのプロジェクト概要
Android StudioもいっぱしのIDEなので,<PROJCET_
ディレクトリにあるファイル群と,*.iml
ファイルです。これらはEclipseでいう.classpath
や.project
に相当します。
Android Studioのプロジェクトウィザードから作成した典型的なプロジェクトの構成は図1の通りです。初期のAndroid Studioと比べるとプロジェクト名やモジュール名は若干変わりましたが,
このうち明らかにバージョン管理の対象にしなくてよいのは,<PROJCET_
ディレクトリ,<PROJCET_
ディレクトリ,build.
が参照するローカル設定の<PROJCET_
ファイルの3つです。
それ以外はバージョン管理対象にしてよいファイルやディレクトリなのですが,
一応,.gitignore
ファイルを参考にすると<PROJCET_
だけはバージョン管理しなくてよい」
バージョン管理のポリシーあれこれ
プロジェクト管理ファイルの話に入る前に,
バージョン管理のポリシーについても,
ケース1. 個人で,かつ同じ環境で開発する場合
最も小さな構成のバージョン管理形態だと思います。要するにバージョン管理システムの役割は
この場合,.gitignore
のままで良いです。
ケース2. 個人だけど,異なる環境で開発する場合
バージョン管理システムを扱うのは自分一人だけれど,
このケースの本質的な状況は,
この時点からAndroid Studioの管理ファイルをどうバージョン管理システムに登録するか悩み始めます.gitignore
のまま共有すると,
ケース3. チームで,皆がAndroid Studioを使って開発する場合
開発者が自分ひとりか,
同一プラットフォームであっても,
この場合は
完全に作業環境を統一するのであればケース1と同じく,.gitignore
のままで十分ですが,
ケース4. チームで,おのおのが好きな環境で開発する場合
個人的にはチーム開発であろうと開発者個人の好みは尊重されるべきだと思うので,
Android Studioへのマイグレーション方法を持っているEclipseでさえ,
- テキストエディタで開発して,
ビルドに gradle
を利用する。 - NetBeansのNBAndroidプラグインを使って,
Android Studioのプロジェクトをマウントする。 - EclipseベースのプロジェクトをGradleエクスポートして,
Android Studioでも開発できるようにする (Android Studio→EclipseはNGだけど, その逆は可能)。
Eclipseとの共用はそれなりに価値がありそうですが,
この場合はケース2,build.
)
前者の場合 ケース3と同じ悩みを抱え,