brewでgitを入れる｜Xcode付属の物と入れ替える手順

brew と git を組み合わせて検索する人がぶつかる症状はほぼ1つに集約される。brew install git は何も文句を言わずに終わるのに、そのあと git --version を打つと数字が前と同じで、入れ替わった気配がない。失敗はしていない。同じ名前の git が2つある状態になっただけで、シェルはまだ古い方を呼んでいる。ここでは何が入ったのか、なぜ古い方が応答するのか、どこを1行直せば入れ替わるのかを順に確かめる。

/usr/bin/gitはgitの本体ではない

出発点になる事実は、macOS の xcode-select のマニュアルに書かれている。このマニュアルの FILES の節には /usr/bin の下にあるパスが大量に列挙されており、そこに置かれているのはプログラムそのものではなく、選ばれている開発ディレクトリの中の同名のツールを呼び出す転送用の仕掛けだと説明されている。列挙の中には /usr/bin/git があり、/usr/bin/git-receive-pack、/usr/bin/git-shell、/usr/bin/git-upload-archive、/usr/bin/git-upload-pack も並んでいる。

つまり /usr/bin/git を叩いたときに動いているのは、/Applications/Xcode.app/Contents/Developer のような開発ディレクトリの中にある実体である。どこが選ばれているかは xcode-select --print-path が返す。切り替える xcode-select --switch は機械全体に効くため管理者権限を要求し、そのシェルの中だけで一時的に変えたいときは DEVELOPER_DIR という環境変数で上書きする。

この構造から3つのことが導かれる。1つ目は、/usr/bin/git の示すバージョンが Xcode の更新で動くことである。beta の Xcode に切り替えれば変わり、戻せばまた変わる。その間、git 自体には何も起きていない。2つ目は、Command Line Tools が入っていない機械では、この転送の仕掛けを叩いた時点でインストールの案内が出ることである。xcode-select --install を別の入口から踏んだのと同じ状態になる。3つ目は、こちらの経路で来る git のバージョンが git の開発の周期ではなく Xcode の出荷の周期に縛られることである。

brew install gitで入るものの中身

formula が持っているバージョンは 2.55.0 である。git 本家が公開している最新のソースリリースも同じ 2.55.0 で、リリースノートの日付は2026年6月29日になっている。つまりパッケージ側と上流は同じ版を指している。

入り方は2通りある。bottle と呼ばれるビルド済みのバイナリが用意されていればそれが降りてきて、無ければソースからのビルドに入る。bottle の用意は次のようになっている。

環境	bottleの用意
Apple Silicon の macOS	Golden Gate、Tahoe、Sequoia、Sonoma
Intel の macOS	Sonoma のみ
Linux	ARM64 と x86_64

依存しているのは pcre2 の 10.48 と gettext の 1.0 で、ソースからビルドするときは pkgconf の 3.0.7 が加わる。curl と expat は macOS に入っている物を使うので、別に入れ直すことはしない。ライセンスは単一ではなく、GPL-2.0-only と GPL-2.0-or-later と LGPL-2.1-or-later と BSD-3-Clause と MIT の組み合わせとして記載されている。

実際にパスへ並ぶ実行ファイルは7つある。git、git-cvsserver、git-receive-pack、git-shell、git-upload-archive、git-upload-pack、そして scalar である。最後の scalar は大きなリポジトリを扱うための道具で、Linux のディストリビューションのパッケージに慣れていると見落としやすい。

gitkとgit-guiとgit-svnは別のformulaにある

ここが問い合わせの多い箇所である。formula の説明には、Tcl と Tk による GUI、つまり gitk と git-gui は git-gui という別の formula に移されたと書かれている。Subversion との相互運用、つまり git-svn も git-svn という別の formula になっている。

したがって brew install git のあとに gitk が見つからないのは、壊れたインストールではなく設計どおりの状態である。git 本家の macOS 向けインストール案内も、GUI の2つを入れる場合のコマンドとして別のものを挙げている。

brew install git-gui

分割されている利点は、使わない依存を抱え込まないことである。gitk を使わない環境に Tcl と Tk を入れる理由はない。逆に、履歴をグラフで追う作業を日常的にするなら、最初の1回で一緒に入れておくほうが後で探す手間がない。

同じ考え方は git-svn にも当てはまる。Subversion のリポジトリを相手にする機会が無い環境で Subversion 側の部品を抱える必要はなく、必要になった時点で別に入れれば済む。以前の Linux のパッケージのように1つで全部入っていた記憶があると、分割を欠品と読んでしまう。formula の説明文にどこへ移したかが書かれているので、見つからない実行ファイルの名前でパッケージ名を引き直すのが早い。

置き場所と、どちらが応答するかを決める1行

Homebrew はパッケージの実体と、コマンドとして呼ばれる名前を別の場所に置く。公式サイトの説明がそのまま根拠になる。

Homebrewは prefix の外部にファイルをインストールしません。各パッケージを Cellar 内の専用の keg にインストールし、そのファイルをHomebrewがインストールされている場所であるprefixへシンボリックリンクします。 出典: brew.sh

prefix は Apple Silicon で /opt/homebrew、Intel Mac で /usr/local になる。インストールが終わった時点で、名前で届く git は2つになる。/usr/bin/git の転送の仕掛けと、prefix の bin にできたシンボリックリンクである。どちらが動くかは、PATH に並ぶディレクトリの順番だけで決まる。

その順番はインストールでは変わらない。シェルの設定ファイルに書く1行が変える。

eval "$(/opt/homebrew/bin/brew shellenv)"

zsh なら ~/.zshrc、bash なら ~/.bashrc に書く。prefix の部分は自分の機械の値に置き換える。この行を書いてシェルを開き直すまで、git という名前は転送の仕掛けを指し続ける。手順を紹介している記事も、この順番の作業が避けられない点を書いている。

Gitが既に存在する場合はHomebrewのインストール後パスを通すという作業が必要になるため、とりあえず今はGitが存在するかどうかだけの確認だけで大丈夫です。 出典: zenn.dev

確認には which -a git を使う。-a を付けると PATH の順に候補が全部並ぶので、先に見つかるのがどちらかがそのまま読める。Homebrew 側が上に来ていれば意図どおり、/usr/bin/git が上なら設定の行が無いか、書いた先が読まれていないか、あとから別の設定で上書きされている。

Intel Macだけ話が変わる

同じコマンドが機械によって1分で終わったりコンパイルを始めたりする理由は、要件の非対称にある。Homebrew の導入手順が挙げる macOS の要件は Apple Silicon の CPU と macOS Sequoia（15）以降で、64ビットの Intel CPU は Tier 3 という位置づけになっている。

開発ツールの要否も対称ではない。Xcode か Command Line Tools が必要になるのは formula をソースからビルドするときで、Apple Silicon では cask と bottle は開発ツールなしで入る。ところが Intel の macOS は bottle を入れる場合でも開発ツールが必要になる。上の表のとおり Intel 向けの bottle は Sonoma までしか用意されていないため、それより新しい環境ではソースからのビルドになり、Xcode か Command Line Tools が前提に戻る。

つまり Intel Mac で brew install git が長くかかるのは異常ではない。想定された経路のうち、遅い側を通っている。

ここで判断が要るのは、待つか経路を変えるかである。git だけが目的で、Xcode も Command Line Tools も入れたくない環境なら、Xcode の転送の仕掛け経由の git をそのまま使う選択も成り立つ。逆に、版を自分で決めたい理由があるなら、開発ツールを入れてビルドを通すほうが後の作業が読みやすくなる。どちらを選んでも、決めた側に PATH の順番を合わせておくことだけは同じである。

どれだけ使われているコマンドなのか

formula のページには利用状況が載っている。直近30日のインストールが 37,186 件、90日で 260,670 件、365日で 1,434,005 件である。30日のうち依頼によるインストール、つまり他のパッケージの依存としてではなく名前を指定して入れられたものが 36,192 件で、ほぼ全部が意図して入れられている。

同じページにはビルドの失敗が 3,900 件と記録されている。bottle がある環境ではまず起きない数字で、ソースからのビルドに入る環境が一定数あることの裏付けになる。

3つの入れ方を並べると、違いは「誰が更新の主導権を持つか」に収束する。

	Xcode Command Line Tools	Homebrew	MacPorts
コマンド	xcode-select --install	brew install git	sudo port install git
版の決まり方	入っている Xcode に従う	2.55.0（上流と同じ）	port の木に従う
置き場所	開発ディレクトリの中（/usr/bin から転送）	Cellar の keg から prefix へリンク	独自の prefix
gitk と git-gui	含まれない	別の formula	別の port

どれも動く。困るのは両方入っていて、どちらが応答しているのかを把握していない状態である。

確認は3つのコマンドで足りる

Xcode を更新したあとに1度だけ打てば、この混乱は戻ってこない。which -a git で PATH の順に候補を出し、git --version で勝っている方の版を読み、xcode-select --print-path で転送先の開発ディレクトリを確かめる。転送の仕掛けが勝っているときは、3つ目の出力がバージョンの説明になっている。

この作業はフォルダを見ることとコマンドを打つことの往復でできている。設定ファイルを開いて1行を足し、シェルを開き直し、which -a を打ち、また設定ファイルへ戻る。フォルダとターミナルとAIが同じ窓にある形に寄せると、いま見ているフォルダでそのままコマンドが打てるので cd の打ち直しが消える。フォルダごとにターミナルが割り当てられる作り方や、Git の状態がその場で分かる点はできることに整理されている。

ソースからのビルドに入った場合は数分待つことになる。画面の前で終わりを待つ必要はなく、手元の iPhone や iPad から Mac のターミナルを読んで返事だけ入れる使い方がiPhone・iPadから続きをに説明されている。Mac だけで使う範囲に費用がかからない線引きは料金にあり、編集機能を持たないことまで含めて役割の範囲を書いたものが他のファイル管理との比較にある。