【ブランチ戦略】git-flowとGitHub Flowゆるふわまとめ
ブランチ戦略の主な2つのワークフローである「git-flow」と「GitHub Flow」についてまとめていきます！
2つのブランチ戦略
まずブランチ戦略とは、
「機能Aと機能Bの開発を同時に進めたいが、各々影響を与えあわない状況下で同時に開発を進めたい」といった場合に活躍する仕組み。
ブランチ戦略とは - Qiita
ということで技術的なワードというよりは、「チーム開発におけるホスティングサービスの利用方法」、もっと具体的に言えば「どのようにブランチを切って、マージして…」というルールのようなものです。
まずはこの2つについて以下のようなイメージを私は持ちました。
具体的な図を見ていきましょう。
git-flow
参照：A successful Git branching model » nvie.com
先ほど「難しいやつ」と述べたように少し図が複雑ですね。
- master
- hotfix
- release
- develop
- feature
という5つのブランチで開発フローが進んでいきます。
さらにこれをメインブランチ・サポートブランチの2つに分けることができます。
1つずつ役割を見ていきましょう。
メインブランチ
master
「master」には、ユーザーにリリース済みのソースコードが管理されています。
develop
「develop」はその名の通り、開発を行うためのブランチです。基本的にこのブランチ上で作業を行うことになります。
サポートブランチ
release
「release」には、リリース直前のソースコードを管理します。プロダクトリリースの前に微調整が行われるのがreleaseです。
hotfix
「hotfix」には、すでにリリースされたソフトウェアで「可及的速やかに」修正が必要なソースコードが入ります。そのためhotflixは修正後すぐmasterにマージされ、その後、developにマージされます。
feature
「feature」は、機能実装やバグ修正のためのブランチです。タスクごとに切り分け、作業を行います。
git-flowの運用イメージ
1,featureブランチで各機能の開発やバグフィックス
2,featureブランチで単体テスト
3,developブランチへマージして
4,ソフトウェアをリリースする段階でreleaseブランチを作成
5,細かいドキュメントの修正やバグフィックス
6,準備が終わってリリースする際には、リリースブランチをmasterブランチへマージし、リリースタグを打つ。
※ソフトウェアリリース後、緊急のバグへの対応は、ホットフィックスとしてリリース。
ブランチ戦略とは - Qiita
GitHub Flow
先ほどのgit-flowと比べるととてもシンプルです。つまり「簡単な方」のブランチ戦略です。
GitHub Flowは以下の6つのルールに従って運用されます。
- masterブランチが常時、デプロイできる状態である
- 作業用ブランチはmasterブランチから作成する（ブランチを切る）
- 作業用ブランチは定期的にプッシュする
- 作業用ブランチをプッシュした後にはプルリクエストを行う
- プルリクエストが承認を受けたらmasterにマージする
- 作業用ブランチがmasterにマージされたらmasterをデプロイする
GitHub Flowは上記のルールに従って運用されます。
小規模開発やスピード感のある開発ではGitHub Flowが採用されることが多いようです！
