読者です 読者をやめる 読者になる 読者になる

nanahara.log

プログラミング関係のノート

Gitのブランチ戦略まとめ

今更話題として盛り上がることは少ない気がするが、自分の中で曖昧になっているので有名そうなものをまとめてみた。

数年前のエントリになるけど、雛形として有名なものだとこの辺りだと思われる

1. A successful Git branching model (git-flow)

A successful Git branching model を翻訳しました

リリースを中心に考えられており、以下の5つのブランチを使用する

  • メインブランチ
    • master : 常にリリース可能な状態。
    • develop : 次のリリースのための最新の開発作業の変更を常に反映する。
  • サポートブランチ
    • Feature branches : 新機能開発用。developから分岐して、developにマージ。(–no-ff フラグ付けて、Fast-forwardしないようにする)
    • Release branches : リリース作業用。developから分岐して、developとmasterにマージ。
    • Hotfix branches : 緊急対応用。masterから分岐して、developとmasterにマージ。

git-flowはこのモデルを補助するためのプラグイン

2. GitHub Flow

GitHub Flow (Japanese translation)

ざっくり言うとmasterブランチとfeatureブランチだけで進めるモデル。

プロダクション環境へのデプロイを毎日行うため、リリース作業というもの自体がないケース。

GitHub Flowとは何だろうか?

  • masterブランチのものは何であれデプロイ可能である
  • 新しい何かに取り組む際は、説明的な名前のブランチをmasterから作成する(例: new-oauth2-scopes)
  • 作成したブランチにローカルでコミットし、サーバー上の同じ名前のブランチにも定期的に作業内容をpushする
  • フィードバックや助言が欲しい時、ブランチをマージしてもよいと思ったときは、 プルリクエスト を作成する
  • 他の誰かがレビューをして機能にOKを出してくれたら、あなたはコードをmasterへマージすることができる
  • マージをしてmasterへpushしたら、直ちにデプロイをする

又、中の人に聞いたGitHub flowの本当の使い方 - Qiitaによると、実際はマージ前にデプロイしているらしい。

マージ前にデプロイすることでさらにユーザーに近いところでフィードバックを受けることができる

3.GitLab flow

GitLab flowから学ぶワークフローの実践

master(アップストリーム)からproduction(ダウンストリーム)に流していくモデル。

Git-flowが複雑さや、GitHub flowがリリース周りの問題点を指摘して、それらを解決しようとしたもののようだ。

  • 環境ブランチ
    • コミットがダウンストリームに流れるワークフロー。
    • ブランチ名と環境名が一致している例だと、masterブランチからpre-productionブランチへマージ(MergeRequest)、pre-productionブランチから、productionブランチへマージといったフロー。
    • Hotfixをcherry-pickしたい場合はfeatureブランチで開発したものをmasterブランチにマージ(MergeRequest)する。この際featureブランチを消さずにmasterがokであれば他のブランチにもマージする
  • releaseブランチ
    • リリース作業時、できるだけ最新のmasterからrelease(stable)ブランチを分岐。
    • releaseブランチ作成後は最小限のbugfixだけをreleaseブランチにマージ。
    • 「アップストリームファースト」。可能であればbugfixはmasterにマージしてから、releaseブランチへcherry-pickする(masterへのマージ漏れを防ぐ)

若干、話が逸れるが、「Googleがブランチを切らない開発をしている」ってホントなの?|CodeIQ MAGAZINEによると、Googleの一部のプロジェクトではブランチを切らないケースがあるらしい。

Googleは様々なプロジェクトを一つのレポジトリで管理しており、ブランチを切らない運用をしていると話しています。 この理由としてAri Shamashは、「各開発で使用する多くのライブラリに関して、管理する必要がないというメリットがある」 そして、フラグを管理しながら進めるとのこと。 フラグを使って管理することが多いようです。つまり、機能に対して条件による制限をかけながら、直接masterに書いていく

所感

最近関わっている自分のプロジェクトではリリース関連の作業がないものがなかなか想像しづらいため、GitHub FlowやGoogleの手法は適用しづらく、本当にケースバイケースだなという印象。

これらのモデルをを参考にしつつチームで要件にあったスタイルを開発が本格化する前に決めていくべきなのかと。