Gitの運用～GitHub Flowとgit-flow～

n-ozawan

2024.04.11

開発手法 git

皆さん、こんにちは。技術開発グループのn-ozawanです。
お花見シーズンですね。近所の公園にある桜も綺麗に咲いてました。

本題です。
初めてGitを触れた方は、Gitでどう運用すればいいのか悩むことかと思います。プロジェクトでGit運用フローなどが整備されていればいいのですが、しっかりとした運用フローがない現場も多くあります。今回はGitの運用フローで有名なGitHub Flowとgit-flowを紹介します。

色々な運用フロー

GitHub Flow

GitHub Flowとは、その名の通り、GitHubの開発で使用されているフローです。非常にシンプルで、GitHub Flowで登場するブランチはmasterと作業用ブランチの2つです。GitHub Flowは以下の３つステップで行います。

masterブランチから作業用ブランチを作成する
作業用ブランチでコードを修正する
Pull Requestを作成して、masterブランチへマージする

GitHub Flowを運用するにあたり、６つのルールが設けられています。

masterブランチは、常時デプロイ可能な状態を保つ
作業用ブランチはmasterブランチから作成する
作業用ブランチを定期的にPushする
Pull Requestでレビューを行い、変更内容が承認されたらmasterへマージする
masterへのマージが完了したら直ちにデプロイする
masterへのマージ後は作業用ブランチを削除する

以上のように、GitHub Flowでは必要最小限の操作で、Git初心者でも扱いやすいフローとなっています。小規模から大規模まで柔軟に適用できる運用フローです。

git-flow

GitHub Flowと似た名前で、「git-flow」という運用フローがあります。git-flowは2010年にVincent Driessen氏がブログに記載(“A successful Git branching model”)したことを切っ掛けに、多くの現場で取り入れられました。

git-flowで登場するブランチは、master、hotfixes、release、develop、featureの５つです。それぞれの意味は以下の通りです。

ブランチ	意味
master	リリースしたソースコードなどを管理するブランチ
develop	開発作業を行うブランチ複数人の作業者がこのdevelopブランチに対して修正内容を反映することで開発を進める。
feature	作業用ブランチ作業者はdevelopブランチからfeatureブランチを作成して、featureブランチで修正などを行う。修正が完了したらdevelopブランチへマージする。
release	developからmasterへマージする際に、リリースするための作業を行うためのブランチ
hotfix	リリース後に発見された障害に対して、緊急対応するためのブランチ

詳細な説明は省きますが、git-flowは複雑な運用を求められます。昨今の開発では１日に何回もデプロイするようなスピードが求められており、それに伴いカナリアリリースなどの継続的デプロイ手法が採用されています。その中でgit-flowのような運用は時代にそぐわなくなってきており、Vincent Driessen氏自身も「GitHub Flowなどのシンプルな運用フローを採用した方が良い」と述べています。

どっちがいいの？

先ほど述べた通り、git-flowはその複雑な運用から、あまりお勧めできません。ではGitHub Flowが良いのかというと、そうとも言えないケースがあると思います。GitHub Flowではmasterブランチにマージされたら、その修正内容が直ちにデプロイされます。常に最新化に保つために頻繁にデプロイを行うプロジェクトではGitHub Flowは良い運用フローと言えそうです。

一方で、月単位もしくは年単位に開発期間を設けて、数ヶ月ごとに修正内容をリリースするケースもあります。また、検証環境や開発環境など、用途によって複数の環境を使い分けたり、複数の大きな対応を並行して行っているプロジェクトもあります。そういったプロジェクトではmasterブランチ１つだけでは対応しきれませんので、masterブランチとは別にdevelopブランチ等で開発した方が良いかもしれません。

現時点においては、銀の弾丸となりえる運用フローは無いように思えます。そのプロジェクトの特性を把握して、運用フローを決めた方が良いでしょう。