iOSアプリ開発のGit運用

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

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

各ブランチの役割

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

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

git-flow コマンドについて

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

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

何がうれしいか

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