Gitブランチ戦略

Gitを、だね。使うわけだよ。
でも、どんな使い方がるあるの？って探した時に、よく似た名前で微妙に違う説明が書いてあって、混乱してしまう。
で、以下にざっと目についたブランチ戦略をリストアップしてみた。

名前 特徴
Git Flow 一番メジャー
Gitコマンドのプラグインとして作られていて、専用のサブコマンドが用意されている
SourceTree でGUI操作が可能。
運用するブランチが少し多い。
ブランチandマージ方式。
GitHub Flow 手動で実施する。
運用するブランチは少ない（といいつつtopicブランチの下は多くなる）。
開発者ごとにリポジトリを保有する。
フォークandプルリク方式。
Gitlab Flow 手動で実施する。
運用するブランチは少し多い。
リリース対象のブランチを用意する。
全員でひとつのリポジトリを参照する。
ブランチandマージ方式。

Git Flow

おそらくGitを使ったワークフローを探すと一番最初に行き当たる手法。
運用管理するブランチが少し多いが、Gitのプラグインなどが提供されており、手順の複雑な部分は隠蔽されている。SourceTreeにGUIのインターフェースもある。
例えば、featureブランチは必ずmasterから分岐し、作業が終わればmasterへマージするなどのルールをプラグインが保証してくれる。
機能追加の最中に緊急でバグ対応を迫られた場合などの手順が用意されている。

ブランチ名称 機能
master すべての基本
開発者は基本的にここにはコミットしない
いつ何時でも、常にリリースできるような状態を保つ。
最後まで生き残る。
develop 作業ブランチ
機能追加はここから分岐し、いったんここへ合流する。
最後まで生き残る。
feature 機能追加
developより分岐し、developへ戻る。
作業が済んだらブランチそのものは削除する。
release リリース準備
全ての機能追加作業が済んだら（つまりdevelopから分岐したfeatureが全てマージされて合流したら）、developから分岐する。
リリースが無事に完了したら、developとmasterの両方にマージすることで、masterとdevelopの同期を取る。
作業が終わったらこのブランチも削除。
hotfix 緊急のバグフィックス
これだけはmasterから分岐する。
不具合対応が済んだら、これもdevelopとmasterの両方にマージすることで、それぞれのブランチの同期を取る。
作業が終わったらこのブランチも削除。

SourceTreeを使った場合の手順とか

参考URL

GitHub Flow

とくにプラグインやGUIはない。手動で実施する。
フォーク先からプルリクを送り、それを受け入れることでレビューが完了とする。
masterブランチは、つねにリリースできるようにする。
(…ことを人間が気を付ける)

ブランチ名称 機能
master すべての基本
つねにリリースできるようにする。
topic トピックブランチ
機能追加・不具合対応に使う。
topic/task_name1
topic/task_name2
などのように、複数のブランチを持つ。

参考URL

GitLab Flow

とくにプラグインやGUIはない。手動で実施する。
関係者全員は同じリポジトリを見る。フォークはしない。
リリース用のブランチを用意する。
GitHubではなく、Gitlab が元となる。
Gitlabでは、ブランチでの作業が終わったらマージリクエストを発行する。
(Githubでも同様の機能はある模様)

ブランチ名称 機能
master すべての基本
topic 機能追加・不具合対応に使う。
production リリースブランチ

参考URL