プルリクエスト／レビューを取り込んだ、よりシンプルなGitHub Flowの運用を図解する：Gitブランチを使いこなすgit-flow／GitHub Flow入門（終）（1/2 ページ）

数回にわたってgit-flowとGitHub Flowを使ったGitの活用テクニックを紹介します。最終回は、GitHubが採用している、git-flowよりシンプルな構成のブランチ管理フローについてです。5つの運用ルールや開発の流れを図を交えて解説します。

» 2014年01月21日 18時00分公開

[岡本隆史，＠IT]

　本連載「Gitブランチを使いこなすgit-flow／GitHub Flow入門」では、これまでgit-flowについて解説してきました。git-flowはプロダクトを厳格にリリースすることを念頭にフローが考えられていますが、プロジェクトによっては、冗長過ぎると感じることもあるかもしれません。本連載の最終回となる今回は、git-flowに比べシンプルなブランチ運用ができる「GitHub Flow」を紹介します。

「GitHub」で採用されている「GitHub Flow」とは

　git-flowは、プロダクトを厳格にリリースすることを念頭においてフローが考えられています。そのため、リリース準備を行うreleaseブランチや緊急の修正をリリースするためのhotfixブランチが用意されています。git-flowの厳密性は理にかなっていますが、プロジェクトによっては、冗長だと思われるかもしれません。

　今回紹介する「GitHub Flow」は、Gitリポジトリのホスティングサービスとして有名な「GitHub」で採用されているブランチの管理フローです。git-flowに比べ、とてもシンプルな構成となっています。

GitHub Flow - Scott Chacon（原文）
上記記事の日本語訳

　git-flowでは、master、develop、feature、release、hotfixとたくさんのブランチを利用しますが、GitHub Flowではmasterブランチと作業用のブランチ（上記ドキュメントでは説明的なブランチと表記）の2種類のブランチのみ利用します。

GitHub Flowの5つの運用ルール

　GitHub Flowでは、ブランチの作り方だけではなく、各ブランチ上での開発の運用も合わせて規定しています。GitHub Flowでは、以下のことを定めています。

【ルール1】masterブランチのものはデプロイ可能である

　git-flowでは、developブランチを利用して開発を進めていましたが、GitHub Flowでは全ての作業をmasterブランチへマージするようにし、ブランチモデルを簡単にしています。しかしながら、ブランチに不具合が混入していた場合、リリースしたサービスに影響を与える可能性があります。masterブランチへマージするブランチは、テスト、レビューされ、masterブランチは常に安定して動作するように保つ必要があります。

【ルール2】masterブランチから各種作業を行うブランチを作成する

　git-flowでは、featureブランチとreleaseブランチはdevelopブランチから、hotfixブランチはmasterブランチから作成されました。GitHub Flowでは、全てのブランチはmasterブランチから作成します。緊急のバグフィックスか、新機能の実装かによってブランチの分岐元を分けるようなことはしません。

　ブランチの名前は、一目見てその作業が分かるような名前を付けます。それによって、現在アクティブなブランチ一覧を見れば、おおよそどのような作業が行われているか分かるようになります。

【ルール3】ブランチを定期的にプッシュする

　git-flowでは、ブランチでの作業をローカルで行いdevelopブランチやmasterブランチへマージした後、共有リポジトリへプッシュする運用がありました。GitHub Flowでは、作業用のブランチを定期的にプッシュすることを定めています。

　定期的にプッシュすることにより、他の担当者に現在の作業状況を共有でき、また、不意のPCの故障からソースコードを守ることにもつながります。

【ルール4】プルリクエストを利用してレビューを行う

　masterブランチが常にデプロイ可能なものにするのに重要なのは、コードレビューです。GitHub Flowは、GitHubのプルリクエストの機能を利用して、ソースコードのレビューを行い、masterブランチにマージします。

【ルール5】マージされたプルリクエストを直ちにデプロイする

　【ルール4】によってブランチがマージされたmasterブランチのコードは、すぐにデプロイします。バグの修正は、バグが混入した時点より発見が遅れれば遅れるほど、時間がかかり、また、発見も困難になります。早期にデプロイし動作確認確認を行うことにより、バスを早期に発見し、修正コストも抑えることができます。

　「本番環境にいきなりデプロイするとバグが混入する可能性もあるので、本番環境へのデプロイはためらわれる」という場合は、本番環境へデプロイする前に動作確認を行うためのステージング環境にデプロイして動作確認を行います。

GitHub Flowの流れ

　実際にGitHub Flowを利用した具体的な流れを見ていきましょう。GitHub Flowの運用の概要を示すと、図1のようになります。

図1　GitHub Flowの運用の流れ

　担当者とレビューアーがいます。担当者は、リポジトリへブランチでの作業内容をプッシュ（【1】）し、GitHubのWebサイトからプルリクエストを作成（【2】）します。レビューアーは、作業内容のレビューをリポジトリやWebサイトを参照しながら行い、レビュー結果をコメントします（【3】）。担当者は、レビュー結果を受け修正内容をプッシュし、再度レビュー依頼を掛け、OKが出たらmasterブランチへマージします。

　以下、実際に各作業について見ていきましょう。