前置き
ソースコード管理に git を使うにあたってブランチ戦略はどうしていますか。
プロジェクト間で作法が大きく違ったり、プロジェクト内でも良く見ると微妙に個々人で操作に癖があったり。
前者は良い。プロジェクト規模などで気分の良いブランチ戦略は異なってくるだろう。
でもあまりに我流のブランチワークだとプロジェクトを移動したときに混乱したりするかも。
後者は良くない。あの人の開発ブランチに必要な開発済み機能が入っていないとか、逆に余計なものが混入しているとか、タグを打つ場所が間違っているとか変な問題を生むかもしれない。
というわけで市井に存在するブランチワークを調べてみる。
今回は git flow
- git flow ← ココ
- github flow
- gitlab flow
git flow(A successful Git branching model)
いきなり図を見るといささか複雑。
それぞれのブランチに集中して見てみる。
登場するブランチ
| 名称 | 役割 | 分岐元 | マージ先 | 備考 |
|---|---|---|---|---|
| master(main) | デプロイ可能な環境を保持する。 | - | - | 削除しない。 |
| develop | 次のリリースに向けた開発用 | master | - | 削除しない。 |
| feature | 機能ごとの開発用 | develop | develop | develop へのマージ時には git merge --no-ff が推奨される。 |
| release | バージョン番号の準備やマイナーなバグフィックスなど、開発タスク外のリリースの準備を行う。 | develop | master, develop | |
| hotfix | リリース済みバージョンに対する緊急度の高い修正を行う。 | master | master, develop | |
| (bugfix) | 緊急度の低いバグフィックスを行う | develop | develop | |
| (support) | 旧バージョンの保守とリリースを行う。 | master | - | 同時に複数のメジャーバージョンを管理する場合必要になってくる。 |
bugfix と support はオリジナルの図には存在しない。
一部のブランチには命名規則がある。(追記対象)
概要
- 開発開始時(プロジェクト開始時)に master から develop を作成する。
- develop から機能ごとに feature を作成し、ここで個々人が開発作業を行う。
- 機能開発完了後、次のリリースにすぐ含める場合は develop へマージする。(feature は削除)
- 次回リリース機能がすべて develop へ合流し、バージョン番号がプロジェクトで決定したら develop から release を作成する。
- release で機能開発以外に当該バージョンのリリースに必要な準備を行う。
- release の整理が終わったら develop と master へマージする。(release は不要であれば削除)
- master からデプロイを行う。
- master へバージョンタグを打つ。(必要であれば support を master から分岐)
長所
- 各ブランチの役割が明確
- リリース済みリソースと開発中リソースがしっかり分離している
- 複数のバージョンの開発や修正を同時並行して進行しやすい
- 将来的にリリースや開発単位での内容の確認がしやすい
短所
- 一見してわかる通り、他のブランチ戦略と比べて明らかに複雑
- git 管理に一定の工数がかかる。デプロイ速度を重視しており、毎日デプロイを行いたいようなプロジェクトの場合無視できない。
- 個人開発や小規模プロジェクトなど複数の機能・バージョンの開発が平行しにくい場合、享受できるメリットが減る。
原文にはさらに多くの図や文章を使って、各ブランチの説明や運用方法が記載されています。
ここに記載した内容はまだまだ一部でしょう。
ですが、これで一応の基本を押さえた運用は可能な程度の情報を押さえていると思います。
参考
A successful Git branching model
[日本語訳]A successful Git branching model
A successful Git branching model を翻訳しました