検索
連載

【図解】git-flow、GitHub Flowを開発現場で使い始めるためにこれだけは覚えておこうこっそり始めるGit/GitHub超入門(終)

本連載では、バージョン管理システム「Git」とGitのホスティングサービスの1つ「GitHub」を使うために必要な知識を基礎から解説しています。最終回は、幾つか存在するバージョン管理のワークフローのうち「git-flow」「GitHub Flow」の概要を解説します。

PC用表示 関連情報
Share
Tweet
LINE
Hatena

 本連載「こっそり始めるGit/GitHub超入門」では、バージョン管理システムGit」とGitのホスティングサービスの1つ「GitHub」を使うために必要な知識を基礎から解説していきます。具体的な操作を交えながら解説していきますので、本連載を最後まで読み終える頃には、GitやGitHubの基本的な操作が身に付いた状態になっていると思います。

 前回記事「たった3つで共存できる、Git/GitHubとSubversion(SVN)の連携、移行に関する基本操作」では、Subversionとの連携や移行について解説しました。

 本連載の最終回となる今回のテーマは「Git/GitHubのワークフロー」です。幾つか存在するバージョン管理のワークフローのうち「git-flow」「GitHub Flow」の概要を解説します。

git-flow

 「git-flow」はVincent Driessen氏の「A successful Git branching model」を基にしたワークフローです。

 他のワークフローと比べると、大規模で複雑な構成になっています。

 デスクトップ/モバイルアプリケーションのように「リリース」を必要とするソフトウェアの開発に適しています。


図1 git-flow

ブランチの種類と用途

 git-flowを使用した開発では「メインブランチ」とそれ以外の「サポートブランチ」を使用します。

  • メインブランチ

 メインブランチには「master」と「develop」の2つのブランチがあります。これらのブランチは常に存在します。

種類 用途
master リリース済みのソースコードを管理する
develop 開発中のソースコードを管理する
  • サポートブランチ

 タスクごとに「フィーチャー」「リリース」「ホットフィックス」のいずれかのブランチを作成し、作業を行います。

 これらのブランチはmasterまたはdevelopブランチから作成され、作業が完了すると削除されます。

種類 分岐元 マージ先 ブランチ名の慣習 用途
フィーチャー develop develop master、develop、release-*、hotfix-*以外 機能実装やバグ修正などの開発作業を行う
リリース develop developとmaster release-* リリース準備作業を行う
ホットフィックス master developとmaster otfix-* 緊急の修正作業を行う

開発フローの例

 git-flowを使用した開発フローの例を見ていきましょう。

  • developブランチを作成する

 まずは、masterブランチからdevelopブランチを作成します。


図2 developブランチを作成
  • 機能実装を開始する

 developブランチからフィーチャーブランチを作成し、機能実装作業を開始します。コミットはフィーチャーブランチに対して行います。


図3 フィーチャーブランチを作成
  • 機能実装を完了する

 フィーチャーブランチでの作業が完了したら、フィーチャーブランチをdevelopブランチにマージします。

 マージ完了後にフィーチャーブランチを削除します。


図4 フィーチャーブランチをdevelopブランチにマージ
  • リリース準備を開始する

 機能実装が終わりリリースできる状態になったら、developブランチからリリースブランチを作成します。

 バージョン番号やドキュメントの更新などのリリース準備作業を行います。


図5 リリースブランチを作成
  • リリース準備を完了する

 リリースブランチでの作業が完了したら、リリースブランチをmasterとdevelopブランチにマージします。

 マージ完了後にリリースブランチを削除します。


図6 リリースブランチをmasterとdevelopブランチにマージ
  • 緊急の修正作業を開始する

 リリース後に緊急の修正作業が発生した場合は、masterブランチからホットフィックスブランチを作成し、修正作業を行います。


図7 ホットフィックスブランチを作成
  • 緊急の修正作業を完了する

 ホットフィックスブランチでの作業が完了したら、ホットフィックスブランチをmasterとdevelopブランチにマージします。

 マージ完了後にホットフィックスブランチを削除します。


図8 ホットフィックスブランチをmasterとdevelopブランチにマージ

 git-flowの概要の解説は以上です。

GitHub Flow

 「GitHub Flow」は「GitHub」の開発で使用されているワークフローであり、「git-flow」に比べてシンプルな構成になっています。

 1日に複数回デプロイを行うようなWebアプリケーションの開発に適しています。


図9 GitHub Flow

6つのルール

 GitHub Flowには以下の6つのルールがあります。【ルール1】が最も重要で、それ以外のルールは【ルール1】を実現するために存在します。

  • 【ルール1】masterブランチは常にデプロイ可能である
  • 【ルール2】作業用ブランチをmasterから作成する(例:new-oauth2-scopes)
  • 【ルール3】作業用ブランチを定期的にプッシュする
  • 【ルール4】プルリクエストを活用する
  • 【ルール5】プルリクエストが承認されたらmasterへマージする
  • 【ルール6】masterへのマージが完了したら直ちにデプロイを行う

開発フローの例

 GitHub Flowを使用した開発フローの例を見ていきましょう。

  • [1]開発作業を行う

 作業開始時に作業用ブランチをmasterブランチから作成します。

 git-flowでは、「フィーチャー」「リリース」「ホットフィックス」のいずれかのブランチをmasterまたはdevelopブランチから作成しますが、GitHub Flowでは、全てのブランチをmasterブランチから作成します。

 ブランチ名は、何の作業を行っているかが分かる名前にします。また、作業用ブランチは定期的にリモートリポジトリにプッシュするようにします。これによって、他の開発者の作業状況を把握できるようになります。

 本ステップで行う作業は、連載第10回記事の「プルリクエスト作成の準備」で解説しています。

  • [2]プルリクエストを行う

 作業用ブランチをmasterブランチへマージできる状態になったら、プルリクエストを作成して他の開発者にコードレビューを依頼します。そして、プルリクエストが承認されたらmasterへマージします。

 GitHub Flowを使用した開発では、プルリクエストを積極的に活用します。作業完了後のコードレビューだけではなく、作業途中の実装への助言を求める場合などにも使えます。

 本ステップで行う作業は、連載第10回記事の「プルリクエストを作成する」「プルリクエストをレビューする」「プルリクエストをマージする」で解説しています。

  • [3]デプロイする

 masterへのマージが完了したら直ちにデプロイを行います。

 GitHub Flowの概要の解説は以上です。

参考ページも見てみよう

 本稿では「git-flow」と「GitHub Flow」の概要を解説しました。

 どちらのワークフローも「厳密な規則」ではありません。また、それぞれのワークフローには長所・短所があります。

 実際の開発では、git-flowまたはGitHub Flowをそのまま使用することはなく、ワークフローの一部を修正するなどの調整が必要になるかと思います。

 git-flowとGitHub Flowの詳しい情報については、以下の参考ページをご覧ください。

Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る