前置き

ソースコード管理に git を使うにあたってブランチ戦略はどうしていますか。

プロジェクト間で作法が大きく違ったり、プロジェクト内でも良く見ると微妙に個々人で操作に癖があったり。

前者は良い。プロジェクト規模などで気分の良いブランチ戦略は異なってくるだろう。
でもあまりに我流のブランチワークだとプロジェクトを移動したときに混乱したりするかも。

後者は良くない。あの人の開発ブランチに必要な開発済み機能が入っていないとか、逆に余計なものが混入しているとか、タグを打つ場所が間違っているとか変な問題を生むかもしれない。

というわけで市井に存在するブランチワークを調べてみる。

今回は git 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 はオリジナルの図には存在しない。
一部のブランチには命名規則がある。(追記対象)

原文にはさらに多くの図や文章を使って、各ブランチの説明や運用方法が記載されています。
ここに記載した内容はまだまだ一部でしょう。
ですが、これで一応の基本を押さえた運用は可能な程度の情報を押さえていると思います。