Mac版のGitHubアプリは3つある|どれを入れるかの決め方

MacのGitHubアプリを入れたのに、結局ブラウザのタブでGitHubを開いている。この状態は入れるものを間違えたわけではなく、そもそも1本ですべてを賄う作りになっていないためです。同じ説明に当てはまる配布物が現在3つあり、それぞれ担当する範囲が違います。自分の作業がどの範囲に多く寄っているかを先に決めれば、入れるものも、ブラウザ側に用意すべきものも自動的に決まります。

同じ呼び名で3つの別物が配られている

1つ目はGitHub Desktopです。Gitの操作を画面から行うための道具で、手元に置いたリポジトリを相手にします。複製、ブランチの作成、コミット、一時退避、履歴の並べ替え、送信までを担当します。名前を聞いて多くの人が思い浮かべるのはこれです。

2つ目はGitHub Copilotアプリです。こちらはかなり新しく、役割がまったく違います。AIのエージェントに作業を任せるためのデスクトップアプリで、複数の作業を並行して走らせ、課題からプルリクエストの取り込みまでを1か所で進める作りになっています。公式の説明ではmacOS・Linux・Windowsに対応し、すべてのCopilotプランで利用できるとされています。

3つ目はブラウザで開くgithub.comそのものです。配布物ではないため比較の対象から外れがちですが、実際の作業時間はここに集中します。

この3つは互いの代わりになるものではありません。同じ週に3つとも使っても無駄にならない程度に、担当が分かれています。

GitHub Desktopが引いている線

GitHub Desktopが見ているのは、ディスク上に置かれたリポジトリの複製です。ファイルの変更を並べ、コミットにまとめ、ブランチを移動し、リモートと同期します。純粋なGitの操作から少しだけ外へ出ていて、プルリクエストのブランチを一覧から取り出したり、そのブランチに対する検査の状況を見て再実行したりもできます。

導入の前に確認しておきたいのは、対応するmacOSの下限です。

macOS 12.0 or later(macOS 12.0以降) 出典: docs.github.com

Big Sur以前で止まっているMacは対象外になります。動作自体は問題ない機械でも、この一行で選択肢が1つ消えます。その場合はブラウザだけが残るので、この記事の判断はそこで終わりです。

一方で、Desktopが担当しないのはGitHubの会話の部分です。課題のやり取りを読む、コードの特定の行にレビューのコメントを付ける、失敗したワークフローのログを読む、プロジェクトの板でカードを動かす、公開の承認をする。これらはすべて別の場所にあります。手元の複製の中に存在しない情報なので、機能が足りないのではなく、対象が違います。

Copilotアプリが解いている問題は別

2つを混同しやすいのは、どちらもGitHubの名前が付いたデスクトップアプリで、新しいほうの説明が古いほうを置き換えるように読めるためです。

Copilotアプリの単位は、手元の複製ではなく作業のセッションです。複数のエージェントを並行して動かし、課題・プルリクエスト・ブランチ・継続的インテグレーションが最初から繋がった状態で、振り分けから取り込みまでを1か所で進めることを目的にしています。内部ではCopilotのコマンドライン版が土台になっています。

ここから2つのことが言えます。GitHub全体を見る道具ではないので、議論の欄を読んだりリポジトリの設定を変えたりするときには結局外へ出ます。そして、Desktopのような差分中心のGit操作の道具でもありません。エージェントに任せる進め方をしていない場合、質問に対して大きすぎる道具になります。

ブラウザから出ていかない画面

ここを正直に並べると、判断が一気に楽になります。コードを書く時間より読む時間のほうが長い立場の人にとっては、1日の大半がこちらに入ります。

通知の一覧、課題のやり取り、行単位のコメントを伴うレビュー、ワークフローの実行ログ、プロジェクトの板、議論、リリース、セキュリティの警告、設定、請求、開発環境の管理。どれもWebの画面です。一部は手元のアプリにも断片的に映りますが、全体を担当しているものはありません。

規則性は単純です。他人が読んで返信する種類のものはWebに残り、ディスク上のファイルに触る種類のものだけがアプリに移ります。レビューを担当する人、課題を振り分ける人、パイプラインを見張る人は、GitHubに使う時間の大半が前者です。Desktopを入れても思ったほど変わらないのは、このためです。

裏を返せば、ブラウザのタブこそ手を入れる価値がある、ということでもあります。一番使う画面が一番雑に扱われている状態は、よくあります。

判断を早めるなら、直近1週間の作業を思い出して数えてみるのが確実です。手元のファイルに触った回数と、他人の書いたものを読んで返信した回数を比べます。前者が多ければDesktopを入れる価値があり、後者が多ければ入れても体感は変わりません。両方が多い場合は、どちらか片方だけを先に整えるほうが結果が出ます。3つとも入れて様子を見る進め方は、どれも中途半端なまま放置されがちです。

通知をどこで受け取るかを決めておく

GitHubの通知は、サイト上の一覧とメールの2系統で届きます。どちらを主にするかを決めていないと、両方が中途半端になります。

メールを主にすると、他のメールに埋もれます。レビュー依頼と広告と請求書が同じ受信箱に並ぶので、優先順位を付ける作業が毎回発生します。フィルタで振り分けたとしても、開くのは結局メールの画面なので、そこからGitHubへ移動する手数が残ります。

サイト上の一覧を主にすると、埋もれ方が変わります。今度はブラウザのタブの中に埋もれます。20枚を超えるタブが並んでいる状態では、固定していても目に入らず、思い出したときに開く運用になります。通知の一覧は、開いていないと機能しません。

独立した窓に入れると、この2つのどちらとも違う置き場所になります。Dockに常に見えていて、他のタブに押し出されず、クリック1回で通知の一覧が開きます。決めるべきなのは、メールを止めるかどうかです。両方を残すと同じ知らせを2回受け取ることになり、どちらも読まなくなります。窓を用意したなら、メール側は必要最小限に絞るほうが機能します。

会社用と個人用で詰まる場所

同じMacに会社のアカウントと個人のアカウントがある状況は珍しくありません。ここで手元のアプリとブラウザは正反対の性格を見せます。

GitHub Desktopは設定の中でアカウントを持ちます。設定のアカウントの欄には、GitHub向けの入り口とGitHub Enterprise向けの入り口が別々に用意されているため、github.comのアカウントと社内向けのアカウントは同居できます。噛み合わないのは、github.comのアカウントを2つ持ちたい場合です。

ブラウザは逆です。1つのプロファイルが保持するセッションは1つなので、もう片方でログインすると先にいたほうが押し出されます。回避策にはそれぞれ代償があります。シークレットウィンドウは閉じた瞬間にログインが消えます。1日に何度もログインし直す運用は、二段階認証の入力が増えるうえ、いずれ違う名義でコミットを送る事故につながります。

プロファイルを分ければセッションの問題は解決します。残るのは見分けにくさで、どちらも同じ見た目の窓としてDockと切替画面に並びます。アカウントごとに独立した窓を作ると、そこまで解決します。アイコンも窓も分かれ、その下のプロファイルも独立するためです。分離される範囲はできることに整理されています。

コミットに乗る名前は別の話

窓を分けると、誰として読んでいるかは解決します。誰として書いているかは解決しません。

Gitはコミットごとに名前とメールアドレスを記録しますが、その値は設定から取られます。どのアプリを使ったかは関係ありません。最初に設定した1組が既定になり、あとから複製した会社のリポジトリにも黙って引き継がれます。

結果として、会社のリポジトリに個人のアドレスの付いたコミットが送られます。相手側からは全員に見えますし、契約上の取り決めから外れる場合もあります。履歴を書き換えて直すほうが、元の間違いより面倒です。その場では警告も出ません。Gitから見れば何も異常が起きていないためです。

対処は、覚えておく努力ではなくリポジトリごとの設定です。作業用のリポジトリの中でアドレスを指定しておけば、そこだけ既定を上書きできます。署名用の鍵やアクセス用のトークンもアカウントに紐づくので、2つのアカウントを本気で使い分けるなら、鍵も2つになります。どのアプリを選んでも共通して下に横たわる話なので、窓を作る前に片付けておくほうが早く済みます。

経路ごとの担当範囲を並べる

作業 GitHub Desktop Copilotアプリ 独立した窓のgithub.com
手元でのコミットやブランチ操作 できる セッション単位 できない
プルリクエストのブランチを取り出す できる できる できない
行単位のコメントでレビュー できない 一部 できる
課題を読んで返信する できない エージェント作業の範囲 できる
失敗したワークフローのログを読む 状況のみ できる できる
プロジェクトの板や議論 できない できない できる
github.comのアカウントを2つ同時 できない できない 窓ごとにできる
必要なmacOS 12.0以降 macOSに対応 ブラウザの条件次第

最後の行が、古い機械では決定打になります。更新が続いているブラウザは、多くのアプリが示す下限より長く使えます。今年は買い替えないMacで一番長く持つ構成は、Webの画面をきちんとした窓に入れたものです。

窓に入れるときに決めておくこと

月曜から固定しているタブと、独立した窓は別物です。差が出るのは次の3点です。

開く先を、一番使う画面にします。レビュー担当なら通知の一覧、保守担当なら特定のリポジトリの課題一覧です。開いた時点で目的の場所にいれば、毎回の移動が1手減ります。

その窓の中でログインし、状態を保持させます。窓ごとに名義が固定されるので、送信の直前に今どちらかを確認する必要がなくなります。2つのアカウントを扱うときに効くのはここです。

拡張機能は意図して選びます。アプリごとに拡張機能をオンとオフで切り替えられるため、会社用の窓と個人用の窓で同じ構成にする必要はありません。設定の場所は使い方ガイドにあります。拡張機能はプロファイル単位なので、新しく作った窓は空の状態から始まります。

同じ考え方が他のサービスにも当てはまることは、対応サービス一覧を見ると分かります。300以上のプリセットからすぐ作れる形で分野別に並んでおり、開発関連だけでなく、ログインを伴うサービス全般で同じ使い分けが起きています。まず1つ試すだけなら費用はかからず、条件は料金に書かれています。

よくある質問

Mac向けの公式GitHubアプリはありますか?

役割の違うものが2つあります。GitHub Desktopは手元のリポジトリを扱うGitの操作用で、GitHub CopilotアプリはAIのエージェントに作業を任せるためのもので、macOS・Linux・Windowsに対応しています。どちらもgithub.com全体を見る道具ではないため、課題やレビューはブラウザ側に残ります。

GitHub Desktopに必要なmacOSのバージョンは?

公式のドキュメントでは、対応するのはmacOS 12.0以降とされています。それ以前で止まっているMacでは動きません。その場合はブラウザだけが選択肢になりますが、ブラウザ自体の更新が続いていれば作業に支障はありません。

GitHubのアカウントを2つ同時にログインしておけますか?

1つのブラウザのプロファイルではできません。保持されるセッションが1つのためです。GitHub Desktopの設定にはGitHub向けとGitHub Enterprise向けの入り口が別にありますが、github.comのアカウントを2つ持つ形には対応していません。プロファイルごとに独立した窓を2つ用意する方法が現実的です。

会社用のリポジトリに個人のアドレスでコミットしてしまいました。

Gitは設定に書かれた名前とアドレスを記録するため、既定のまま作業すると起こります。今後の分はリポジトリごとに設定を上書きすれば防げます。すでに送ってしまった分は履歴の書き換えが必要になるので、同じことが起きていないか他のリポジトリも1件ずつ確認しておくと安全です。

記事一覧へ戻る