MacでGitを使う｜どれが動いているかを先に確かめる

git mac で検索して出てくる記事は、ほとんどが「入れ方」から始まる。ところが実際に手が止まるのは、入れられないからではない。入れたつもりなのに古いバージョンが動いている、ターミナルとエディタで挙動が違う、ファイル名の大文字と小文字で差分が出る、認証を聞かれる回数が減らない。この4つが多い。原因は入れ方ではなく、Macには最初からGitが入っているという前提を踏まないまま2つ目を入れてしまうところにある。順番としては、いま何が動いているかを確かめるのが先で、入れるかどうかはその次だ。

Macには最初からGitが入っている

新しいMacでターミナルを開いて git --version と打つと、多くの場合そのまま答えが返る。これはインストールを忘れていたわけではなく、AppleがXcode Command Line Toolsの一部としてGitのバイナリを配っているためだ。バージョンの末尾に付く表記で、それが判別できる。

$ git --version git version 2.39.3 (Apple Git-146) (Apple Git- のように表示されている場合、元からmacにインストールされているものが使用されています。) 出典: qiita.com

末尾の括弧が手がかりになる。Apple Git- と付いていればAppleが配っているもの、付いていなければ自分で入れたものが動いている。コマンドがまだ入っていない状態で打つと、Xcode Command Line Toolsを入れるかどうかを尋ねる画面が出る。入れる操作は xcode-select --install で、Gitだけでなくコンパイラや標準的な開発用のコマンド一式が同時に入る。

この配布経路には性質が2つある。1つは、更新のタイミングをAppleが決めるという点だ。OSの更新に合わせて上がるので、公開されたばかりの機能や設定項目が使えないことがある。もう1つは、GUIの道具が同梱されていないという点だ。Git公式の案内では、コミット用の画面である git-gui と履歴を見る gitk は、Homebrewで別に入れる手順として案内されている。Appleの配布物を使い続けるかどうかは、この2点をどう見るかで決まる。

入れ方は3つ、選ぶ基準は更新を誰がするか

Git公式のmacOS向けの案内は、現時点で入れ方を3つ並べている。過去にあった単体のインストーラは、もう案内から外れている。

入れ方	コマンド	更新の主体	向く相手
Xcode Command Line Tools	xcode-select --install	Apple	追加の道具を入れたくない人
Homebrew	brew install git	自分	新しい版を早く使いたい人
MacPorts	sudo port install git	自分	既にMacPortsで揃えている人

公式サイトが示している最新版は2.55.0で、Homebrewとソースからの構築はここに追いつく。一方で、公式のページには「ソース以外の配布物は第三者によるもので、最新のソースリリースに追いついていない場合がある」という注意書きが添えられている。つまり、どの経路を選んでも版が1つに揃うわけではない。

かつて広く使われていた単体のインストーラについても、同じページに経緯が書かれている。Tim Harper氏が提供していたものはバージョン2.33.0、2021年で止まっており、それ以降の更新も予定もないため、公式からのリンクは外された。古い記事の手順をそのままたどると、ここで行き止まりになる。検索で見つけた手順が何年のものかを先に見ておくと、この無駄が省ける。

Git本体の費用については迷う場所がない。GNU GPLで公開されている無料のソフトウェアで、上の3つの経路はどれも支払いを伴わない。費用が発生するのは、この上に載せるGUIの道具や、リモートの置き場所を借りる部分だけだ。

どのGitが動いているかはPATHの順番で決まる

Macで一番紛らわしいのが、2つのGitが同時に存在する状態だ。Appleのものは /usr/bin/git、Homebrewで入れたものはApple Silicon機なら /opt/homebrew/bin/git に置かれる。どちらが動くかは、シェルの環境変数PATHに並んだ順番で決まり、先に見つかったほうが勝つ。

確かめ方は which -a git で、見つかった場所が上から順に出る。1行目が実際に動いているものだ。git --version の末尾に Apple Git- が付くのに、Homebrewで新しい版を入れたはずだという状況は、ここで説明がつく。Homebrewの置き場所がPATHの後ろに回っているか、そもそもPATHに入っていない。

macOSの既定のシェルはzshなので、PATHの追記先は ~/.zprofile か ~/.zshrc になる。Homebrewを入れたときに案内される初期化の1行を ~/.zprofile に書いておくと、ログイン時に置き場所が前に入る。書き足したあとは新しいターミナルの窓を開くか、source ~/.zprofile を打って読み直させる。

ここで見落としやすいのが、エディタやAIの道具から呼ばれるGitだ。GUIのアプリはシェルの初期化ファイルを読まないことがあり、その場合はログイン時の環境だけを見る。ターミナルでは新しい版が動くのに、エディタの中では古い版が動くという食い違いは、この差から生まれる。挙動が違うと感じたときは、両方から git --version を打って突き合わせるのが早い。

Macだからこそ効く設定が3つある

Git本体の設定のうち、Macのファイルシステムに直接関わるものが3つある。どれも公式の設定一覧に説明があり、他のOSでは出番がない。

1つ目は core.ignoreCase だ。APFSやHFS+のように大文字と小文字を区別しないファイルシステムで、Gitが動きを合わせるための内部的な変数だと説明されている。既定は false だが、git clone と git init はリポジトリを作るときに環境を調べ、必要なら true を設定する。同じ資料は、この値を手で変えると予期しない動きになる可能性があるとも書いている。つまり自分で切り替える対象ではなく、Makefile と makefile が同じものとして扱われる理由を知っておくための項目だ。

2つ目は core.precomposeUnicode で、これはmacOSの実装だけが使う設定だと明記されている。macOSはファイル名のUnicodeを分解した形で扱うため、濁点や半濁点を含む日本語のファイル名が、見た目は同じでもバイト列としては別物になる。true にすると、Gitがその分解を元に戻す。LinuxやWindowsと同じリポジトリを共有する場面では、これが入っているかどうかで差分の出方が変わる。

3つ目は core.protectHFS で、HFS+上で .git と同一視されてしまうパスのチェックアウトを拒む設定だ。既定はmacOSでのみ true で、他の環境では false になっている。悪意のあるリポジトリからの保護が目的なので、触る理由はほぼない。3つとも共通しているのは、3つすべてがファイル名の扱いに関わるという点で、Macで差分が読みにくいときはここを疑う順番になる。

認証の置き場所を先に決めておく

HTTPSでやり取りする場合、パスワードやトークンをどこに覚えさせるかを決めないと、同じ入力を何度も求められる。macOSには git-credential-osxkeychain という補助プログラムが組み込まれており、キーチェーンに保存する仕組みは最初から使える。ただしGitHubの案内は、この経路を「個人アクセストークンを手で設定した人向け」と位置づけ、SSHに移るか、Git Credential Managerに上げることを推奨している。

Git Credential Managerを選ぶ場合、macOSでの手順は短い。Homebrewで brew install --cask git-credential-manager を打つだけで、git config を自分で書く必要はないとGitHubの資料に書かれている。次にHTTPSのURLで認証を求められたとき、ブラウザの窓が開いてログインに進み、二段階認証もその流れの中で済む。トークンを作って貼り付ける作業がなくなるのが、この経路の実利だ。

SSHを選ぶ場合は、鍵を1つ作ってアカウントに登録すれば、入力を求められる場面そのものが消える。どちらが良いかは、複数のアカウントを1台で使い分けるかどうかで分かれる。1台1アカウントならSSHが単純で、業務と個人で行き先が変わるならHTTPSと認証情報の管理のほうが切り替えを説明しやすい。

古い認証情報が残っていると、存在するリポジトリに対して「見つからない」という返事が来ることがある。Gitには、見せてもらえない非公開のリポジトリと、存在しないリポジトリを区別する手立てがないためだ。URLの綴りを疑う前に、保存されている認証情報がどのアカウントのものかを見るほうが早い。

覚えることの多さは、道具の置き方で減らせる

Gitに対する評価は、利点と難所がはっきり分かれている。利点は、変更の履歴が全部残ること、複数人で同じファイルを触っても後から順序をたどれること、そして無料で始められることだ。難所として挙げられるのは、操作の入口がコマンドであるという点に集中している。

Gitの情報を検索するとわかりますが、操作はコマンド（ターミナル）で行います。最初は「覚えることが多い」と感じやすい部分です。たとえば git init, git add, git commit といったコマンドを順番に使う必要があります。とはいえ、よく使用するコマンドは決まっているので使いながら覚えていきましょう。 出典: note.com

よく使う操作が絞られるという指摘はそのとおりで、そこは慣れで片付く。残るのは、覚える量ではなく往復の回数だ。フォルダを開いて対象のファイルを見て、ターミナルに移ってコマンドを打ち、出力のパスを読んでまたフォルダに戻る。1回あたりは数秒でも、1日に何十回も起きる。

ここで効くのは、コマンドを覚える努力ではなく、窓の置き方のほうだ。フォルダとターミナルとAIが同じ窓にある形にすると、対象を選んだ状態でそのパスに対して打ち、結果をその場で読むところまでが1画面で終わる。どの操作がそれに当たるかはできることに一覧がある。Gitの設定ファイルや .git の中を見るような、隠れた場所を行き来する作業ほど差が出る。

同じ用途を他の道具がどう解いているかを横に並べたい場合は他のファイル管理との比較が近い。ターミナルを内蔵したもの、プレビューに強いもの、リモート接続に強いもので設計が違うので、往復の多い人はどこを内蔵しているかで基準が変わる。費用の考え方は料金にまとまっている。日本語以外で使う場面があるなら対応言語も見ておくと選び直しが減る。

手元のMacに置いたまま外出する場面もある。移動中にiPhoneやiPadから状態を見て続きを返す方法はiPhone・iPadから続きをにある。残った細かい疑問はよくある質問に揃っている。

進める順番を1つに決めるなら、こうなる。まず which -a git と git --version で何が動いているかを確かめる。次に、更新を自分でしたいかどうかで入れ方を選ぶ。最後に認証の置き場所を決める。この3手を先に済ませると、あとから出てくる不具合の切り分け先が半分に減る。