MacでGit flowを使う｜1人の作業に要る枝だけ残す

Macでgit flowを始めようとして検索すると、「brew install git-flow-avh と打つ」と書かれた記事が並びます。その通りに打っても、いまは何も入りません。git flowという道具は名前が3つに分かれていて、そのうち2つは開発が止まり、Homebrewでは片方が廃止予定に入っています。ここでは、2026年9月時点でMacに入れられるものがどれなのかを確かめたうえで、1人で作業する人が本当に要る枝はどれかまで絞り込みます。

git flowという言葉は、考え方と道具の両方を指している

まず切り分けが必要です。git flowという言葉は、少なくとも3つのものを指して使われています。

1つ目は枝の使い分けの考え方です。Vincent Driessen氏が2010年に公開した記事が出典で、master と develop を常設の枝として持ち、feature・release・hotfixの3種類を必要なときだけ作って消すという設計です。考え方を説明した元の記事は今も読めます。

2つ目は、その考え方を短いコマンドで実行できるようにしたシェルスクリプトです。git flow feature start のように打つと、枝を作って移動するところまでを1回で済ませてくれます。標準のGitに入っている機能ではなく、あとから足す拡張です。標準側で同じことをするなら、git branchの説明書にある git branch <名前> と git switch を組み合わせる形になります。

3つ目は、その拡張の実装です。ここが分かれています。最初の実装は作者の名前から nvie/gitflow と呼ばれ、機能を足した派生が gitflow-avh と呼ばれました。Homebrewで入れるときの名前が git-flow と git-flow-avh に分かれていたのは、この2つに対応していたためです。

検索して出てくる記事が食い違って見えるのは、書き手がこの3つのどれを指しているかを明示していないからです。考え方の話なら今でも有効で、道具の話なら情報が古くなっています。読むときに、その記事が枝の設計を語っているのか、インストール手順を語っているのかを先に見分けると混乱が減ります。

2026年9月時点で入れられるのはgit-flow-nextだけ

Homebrewの公式の一覧を見ると、状況がはっきりします。

git-flow の項目は残っていますが、版は0.4.1で止まったままで、廃止の印が付いています。廃止された日付は2025年12月19日、理由として示されているのは「repo_archived」、つまり配布元のリポジトリが凍結されたことです。そして無効化の予定日として2026年12月19日が入っています。この日を過ぎると、Homebrewからは入れられなくなります。Homebrewのgit-flowの説明ページで確認できます。

配布元も止まっています。最初の実装のリポジトリは凍結済みで、星の数は26,783と多いものの、新しい変更は入りません。機能を足した派生であるgitflow-avhのリポジトリも凍結済みで、最後に手が入ったのは2023年8月です。Homebrewには git-flow-avh という項目そのものが無くなっており、古い記事の手順をそのまま打つと「そんな名前は無い」と返ってきます。

2016年に書かれた記事は、当時の正しい手順をこう記録しています。

次にプロジェクトのルートディレクトリに移動し、git-flowの初期化をします。 出典: qiita.com

初期化の考え方は今も同じです。変わったのは、その前段のインストール対象です。

いま手入れが続いているのは git-flow-next です。Go言語で書き直した実装で、Homebrewでの版は2.1.0。配布元のページには、元のgit-flowとgitflow-avhの両方がすでに終了しているという説明と、既存のgit-flowのリポジトリでもそのまま動くという説明が並んでいます。作っているのはMac用のGitクライアントを出している会社で、リポジトリは2026年9月にも更新されています。

入れて初期化するまでの手順

作業は3つに分かれます。どれも追加の費用はかかりません。

1つ目はインストールです。Homebrewが入っているMacなら brew install git-flow-next の1行で終わります。古い git-flow が入っている場合は、両方が同じ名前の実行ファイルを入れるため衝突します。Homebrewの説明にも、この2つは同じバイナリを入れるので同時には使えないと書かれています。先に古いほうを外してから入れる順番になります。

2つ目は初期化です。対象のリポジトリの一番上の階層に移動して git flow init と打つと、常設の枝の名前と、feature・release・hotfixの接頭辞を順に聞かれます。既定のままEnterを押し続けても構いませんが、ここで決めた内容はリポジトリの設定として書き込まれ、あとから全員に影響します。組織で使うなら、この場で決めずに先に相談する対象です。

3つ目は動きの確認です。git flow version で版が返れば、Gitが git flow という下位コマンドとして認識できています。ここで「flowはgitのコマンドではない」と返る場合は、実行ファイルの名前かパスの問題です。

覚える形はほぼ2つだけです。git flow feature start 名前 で枝を作って移り、git flow feature finish 名前 で元の枝に戻して統合し、要らなくなった枝を消します。git-flow-nextでは、いま居る枝の種類を自動で判別して git flow finish だけでも通る短縮形が用意されています。feature・release・hotfixのどれに居るかを毎回打ち直さずに済みます。

1人の作業では、常設2本のうち1本が空回りする

ここからが本題です。元の設計は、複数人が並行して作業し、出荷したものに後から緊急の修正を当てる前提で組まれています。常設の枝を2本持つのは、「いま世に出ている状態」と「次に出す状態」を分けたいからです。

1人で作っていて、出荷が週に何度もある場合、この2本は中身がほとんど同じになります。develop に入れたものが数時間後には master に移り、また同じ差分が両方に載る。統合の作業だけが増えて、分けたことの見返りがありません。

考え方の作者自身が、後から注意書きを足しています。2020年3月5日の日付で、この設計は2010年に考えたもので、Git自体が生まれてからそれほど経っていない時期のものだ、と前置きしたうえで、継続的に出荷する作りの製品には別の形が向くという趣旨が書かれています。設計そのものを否定しているのではなく、前提が合う場合に使うものだという整理です。

1人の作業で残す価値があるのは、次の2つです。

• feature系の枝。手を付けた作業を途中で止めて別の用事に移れるようにするため。作業ごとに名前が付くので、git branch の一覧がそのまま持ち物の一覧になります
• hotfix系の枝。出荷済みのものを直すとき、作りかけの機能を巻き込まずに直せるようにするため

逆に、1人で週に何度も出す作りなら、release系の枝と常設2本立ては省いても困りません。出荷前に固める期間が無いなら、固めるための枝も要りません。

git-flow-nextが枝の名前と統合の方法を設定で変えられるようにしているのは、この調整を見越した作りです。道具を入れてから考え方を丸ごと受け入れる必要はなく、要る枝だけ残す形に寄せられます。

入れたのにgit flowが動かないときの見分け方

うまくいかないときの原因は、だいたい3つに分かれます。

1つ目は、古い手順をそのまま打っている場合です。brew install git-flow-avh と打って「そんな名前は無い」と返るなら、これに当たります。Homebrewに項目が無いので、更新しても再試行しても結果は変わりません。

2つ目は、実行ファイルの名前です。Gitは git-なにか という名前の実行ファイルをパスの中から探し、見つかれば git なにか として呼べるようにします。この仕組みなので、配置したファイルの名前が git-flow でないと git flow として認識されません。手で配置した場合にここを外しやすく、配布元の説明でも、ファイル名は正確に git-flow でなければGitが下位コマンドとして検出しない、と念を押しています。

3つ目は、パスの一覧に入っていない場所へ配置した場合です。git flow version が通らないときは、まずファイルがどこにあるかを確かめ、その場所がパスの一覧に含まれているかを見ます。

見落としやすいのが、Homebrewで入れたものが2つ並んでいる状態です。古い git-flow を外さずに新しいほうを入れようとすると、同じ名前の実行ファイルを入れる関係で片方が優先され、意図しない側が動きます。git flow version が返す内容が想定と違うときは、まず入っている項目の一覧を見て、片方だけに絞ってから確認をやり直します。どちらが動いているか分からないまま手順を試し続けると、原因の切り分けができません。

初期化の側で詰まる場合もあります。git flow init はリポジトリの中で動かすものなので、リポジトリではない階層で打つと先に進みません。また、まだ1つもコミットが無い状態で初期化すると、常設の枝が作れずに止まることがあります。先に空のコミットを1つ作ってから初期化すると通ります。

枝を切る作業は、覚える量より切り替えの回数が効いてくる

git flowを使う目的を、コマンドを短くすることだと捉えると効果が小さく見えます。git flow feature start x と git switch -c feature/x は、打つ手間がほとんど変わりません。差が出るのは、作業の前後に起きる確認の回数です。

枝を切る前に、いまどのファイルに手を付けているかをフォルダの一覧で確かめる。切ったあとに、意図した枝に居るかをターミナルで確かめる。統合したあとに、消したはずの枝が残っていないかを一覧で見る。生成されたファイルが混ざっていないかを、また別の窓で見る。作業そのものは数秒でも、この行き来が積み上がります。

窓を数えると、フォルダの窓、ターミナルの窓、AIに聞く窓の3つを開いている人が多くなります。片方で見た枝の名前をもう片方に打ち直すだけで数秒かかり、それを日に何十回も繰り返します。フォルダとターミナルとAIが同じ窓にある状態にすると、この打ち直しが無くなります。一覧で選んだフォルダがそのままコマンドの対象になり、出力を同じ画面で読めるからです。

ターミナルを内側に持つファイル管理で何がどこまでできるのかはできることに一覧があり、標準のFinderや他のアプリとの違いは他のファイル管理との比較に整理されています。Macを手元に残したまま出先から作業の続きを確かめる使い方はiPhone・iPadから続きをが該当し、費用の考え方は料金、導入前に迷いやすい点はよくある質問にまとめられています。日本語以外で使う場合の対応範囲は対応言語に載っています。

枝の設計は2010年から大きく変わっていません。変わったのは、その設計を実行する道具の名前と、確認のために開く窓の数です。前者は公式の一覧を見れば分かります。後者だけが、いまも作業時間を押し上げたまま残っています。