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に書いていく