質問: 現在、とあるWebアプリの設計段階でそろそろGitリポジトリなどの準備を進めていきたいと考えています。 今回の構成として、 * Web上のRailsアプリ(APIも実装) * クライアント1 iOS * クライアント2 Android となっています。 これら3つをまとめて一つのリポジトリで管理するのが良いのか、それとも別で `hogeapp`, `hoge-ios`, `hoge-android`というように別々にリポジトリを分けて管理した方が良いのか、決めかねています。 もし、まとめるとなると以下のようなものを想定しています。 ``` リポジトリroot/ ├ ├ android/ ├ ios/ └ rails/ ``` 経験則などで、一つにまとめたほうがGitHub通知の連携の管理が楽だったり、などアドバイスが頂ければと思い質問させて頂きました。 よろしくお願いいたします。
回答: 業務で、同様の構成のサービスを 「モジュールごとに別々のリポジトリを(Githubに)作成」 する方式で管理したことがあります。 その感想を、以下に記載させていただきます。 ### 欠点 特に不便に感じたのが「Issue の管理」でした。 例えば、1つの機能開発が複数のモジュールに改修を要することはよくあることですが、 その際、 「どのリポジトリに Issue を作成すれば良いのか?」 と、毎回、悩むことになりました。 結局、 * 改修を要する全てのリポジトリに Issue を作成し、 * その中のどれか1つの Issue をマスターとし、 * その他の Issue には`See [マスターの Issue の URL]`などと記述する という対応を取っていたのですが、面倒な上に、 「せっかく Issue を作成したのに後になってそのモジュールに改修が不要だったと判明し、そっと Issue をクローズする」 という、切ない思い(w)をすることもありました。 また、エンジニア以外の人にとっては通常、 「どの案件がどのモジュールに影響を及ぼすのか」 などは分からないので、Github の Issue を共通の案件管理ツールとして使うこともできませんでした。 (これに関しては、「それだけが理由」というわけではありませんでしたが) 今、思えば 「Issue を作成するリポジトリをどれか1つに決め、そのリポジトリ上で一元管理する」 という方法もあったかも知れませんが、それはそれで、別の問題や"やりにくさ"がありそうな気もします。 ### 利点 逆に、利点としては 「モジュールごとの開発/テスト環境や、デプロイの仕組みを構築しやすい」 ということでしょうか? 1つ1つのリポジトリのサイズが小さくなるので、 「`git clone`や`git checkout`が遅くてイライラする」 というようなことも、避けられたかと思います。 個人的には、次回、同様の構成のサービスを開発する際は 「1つのリポジトリで全てのモジュールを管理」 する方式を採りたいと考えています。 以上、ご参考までに。