iOSアプリ開発のGit運用

iOSアプリはリリースサイクルが長くなりがちなので、GitHub Flowではなく、git-flowを参考にしたフローを使っている。

仕事もプライベートもこのフローで今のところ問題はない感じ (複数人開発含む)。

各ブランチの役割

基本的に普通の git-flow と変わらないけれど、AppStore がからむとこを中心に説明します。

• master
  • 現在AppStoreで配布中の最新バージョンと常にイコール
• release
  • リリース準備ができたらdevelopから分岐する。AppStoreでリリース申請通過後にリリース完了した時点でmasterとdevelopにマージする。リリース前にrelease上で変更があった場合は適宜develop featureにマージする。
  • リリース後にタグを打つのを忘れずに。git tag -a v1.0.1 -m 'my version 1.0.1'
• develop
  • 開発ブランチ。次期バージョンの要件を満たしたらreleaseブランチを作成する。
• feature
  • developブランチから作成して、作業完了したらdevelopにマージする。
• hotfix
  • AppStoreで配布中のバージョンで障害が発生した場合にmasterから作成する。AppStoreでリリース申請通過後にリリース完了した時点でmasterとdevelopに(必要であればrelease featureにも)マージする。

git-flow コマンドについて

git-flowコマンドは上記のようなフローでの開発を補助するgitのサブコマンドです。 各ブランチの作成やマージが便利になるコマンドが用意されているけど、プルリクエストやGithub上でのマージは考慮されていない。

上記フローを実践するために必ずしもgit-flowコマンドを使う必要はない。僕は普通のgitコマンドでブランチ切ったり、Github上のプルリクエストからマージしたりしてる。

何がうれしいか

• iTunes Connectで申請中に、次のバージョンの機能をdevelopにさくさくマージできる
  • GitHub Flow だとmasterとトピックブランチだけなのでシンプルで良いんだけど、iOSアプリはリリース申請期間が長いし、その間も開発はしたいので無理が出てくる
  • 日次でdevelopとreleaseブランチをそれぞれ DeployGate 等に配布する仕組みがあれば検証する人も便利
• リリース版のアプリで不具合があった時に、常にmasterがリリースされたものと同一だと安心感がある。hotfixで障害対応が可能
• releaseブランチをプルリクエストしておくとWhat's New in this Versionをまとめるときに便利