iOS のライブラリ管理で一番メジャーな方法として、 CocoaPods がある。
RubyGems や npm のようにライブラリの依存管理などをやってくれるやつだ。
普通 RubyGems を使うときは vendor/bundle を gitignore するし、 npm では node_modules を gitignore する。
ただし、 Cocoapods は Pods ディレクトリをソース管理することを推奨している。
CocoaPods Guides - Using CocoaPods
Whether or not you check in your Pods folder is up to you, as workflows vary from project to project. We recommend that you keep the Pods directory under source control, and don't add it to your .gitignore. But ultimately this decision is up to you:
ソース管理することの理由はいくつか書いてあって、
- ライブラリインストールする手間を省ける
- GitHub がサーバダウンしてても開発に影響がない
- ライブラリのレポジトリが消えてても開発に影響がない
などが書かれている。
ソース管理しないメリットも書かれていて、
- ソースコードのレポジトリが小さく保たれる
- Podfile.lock と同一のライブラリをインストールできる (取得元が消えていなければ)
- ライブラリの version 違いによるコンフリクトを防げる
などが書かれている。
しかし、ライブラリをソース管理することで大きなデメリットとなるのが、プルリクエストである。
プルリクにライブラリのコードが入ってしまうため、レビュワーの負担が大きくなる。
レビューすべきファイルか都度確認しなければならない。
対策としては、ライブラリを追加するだけのプルリクを出すくらいしか思い浮かばない。
とはいえ、ライブラリを素振りして、使い心地を確認した上でプロダクトに入れていくか決めたいため、ライブラリを追加するためだけのプルリクはダルい。
Podfile.lock にコミットハッシュがのっているし、基本的には Pods/* は .gitignore しても問題ないと思う。
CocoaPods の推奨とは違うことになるけど、 git clone して pod install してから build してもらう運用でやっていこうと思う。
とはいえ、まだ開発始まったばかりなのでやりながら考えます。
* 個人で開発しているアプリはプルリクの必要がないため、 Pods/* もソース管理しています。