GitHub Desktopで複数アカウントを使い分ける｜押し先を間違えない

github desktop 複数 アカウントで検索する人の多くは、仕事用と個人用の押し先を一度取り違えた経験を持っています。困るのはサインインのやり方そのものではなく、どちらのアカウントで作業しているのかが画面から読み取りにくいことです。ここでは設定画面のどこで何が決まるのかを分解し、リポジトリごとに作成者情報を分ける手順と、ブラウザ側の切り替えとの噛み合わせ方まで並べます。

複数アカウントという言葉には、2つの別の話が混ざっている

GitHub Desktopで複数のアカウントを扱うという相談は、ほぼ必ず2つの層に分かれます。1つはアプリがどのアカウントの資格情報でGitHubに接続するかという層です。もう1つは、作ったコミットにどの名前とメールアドレスが刻まれるかという層です。この2つは同じ設定画面の中にありながら、別々の場所で別々に決まります。

事故が起きるのは、ほとんどの場合あとの層です。サインイン先が正しくても、Git構成の作成者情報が個人用のままなら、会社のリポジトリに個人のアドレスが残ります。逆に作成者情報を会社用に直しても、サインインしているアカウントに書き込み権限がなければプッシュは弾かれます。片方だけを直して安心してしまうのが、押し先を間違える典型的な流れです。

そして厄介なのは、どちらの層も画面の端に小さく表示されるだけという点です。現在のリポジトリ名はウィンドウ左上に出ますが、いま何者としてコミットしようとしているかは、コミット欄のアバターを見るまで分かりません。画面の作りが原因なので、気をつけるという対策では再発します。層を分けて理解し、設定で分けるところまで持っていく必要があります。

設定の[Accounts]でサインインできる先を確かめる

Macでは、メニューバーの[GitHub Desktop]から[Settings]を開き、[Accounts]ペインを見ます。ここに[Sign Into]ボタンが並んでいて、GitHub.comと、GitHub EnterpriseまたはGitHub Enterprise Serverを別の枠として扱います。データ所在地付きのGitHub Enterprise Cloudにサインインする場合も、Enterprise側のボタンを使います。Windowsでは[ファイル]メニューから[オプション]を開くと同じペインに届きます。

サインインの流れはブラウザ経由です。[ブラウザーを使ってサインイン]の画面で[ブラウザーで続行]を押すと、GitHub Desktopが既定のブラウザを開きます。2要素認証を設定している場合は、SMSで受け取ったコード、またはTOTPアプリで生成したコードを入力します。公式の手順では、ユーザー名とパスワードによる認証はサポートされていないと明記されています。

ここで押さえておきたいのは、枠がGitHub.comとEnterpriseで2つに分かれているという構造です。仕事用と個人用のどちらもGitHub.comのアカウントである場合、アプリの[Accounts]に同時に2つを並べる作り方にはなっていません。片方で作業するあいだ、もう片方はサインアウトした状態になります。この前提を知らずに切り替えボタンを探し続けると、時間だけが消えます。

GitHub で複数のアカウントを使用する必要がある場合は、アカウントにサインインし、アカウントを切り替えることができます。常に再認証する必要はありません。 アカウント切り替えは、個人用アカウントとサービス アカウント (マシン ユーザーとも呼ばれることもあります) がある場合、または マネージド ユーザー アカウント を使用する企業で個人用アカウントと Enterprise Managed Users を切り替える必要がある場合に使用できます。 出典: docs.github.com

コミットの名前とメールは、サインインとは別に決まる

作成者情報は[Settings]の[Git]ペインで決まります。名前の欄に入れた文字列と、メールのドロップダウンで選んだアドレスが、そのままグローバルのGit構成に書き込まれます。ドロップダウンにはGitHubアカウントに関連付けられたアドレスが並び、[その他]を選べば任意のアドレスを直接入力できます。すでにパソコンのグローバルGit構成に名前とアドレスがある場合、GitHub Desktopはその値を見つけて使います。

リポジトリごとに変えることもできます。[現在のリポジトリ]ドロップダウンで対象を選び、[リポジトリ]メニューから[リポジトリの設定...]を開いて、左のサイドバーの[Git 構成]で[このリポジトリの場合]の[ローカルの Git 構成を使用する]を選びます。この設定はそのリポジトリだけグローバルの設定を上書きします。特定のリポジトリで別の仕事用アドレスを使う必要があるときに効きます。

安全装置も1つ用意されています。Git構成のメールアドレスが、いまサインインしているGitHubアカウントに関連付いたアドレスと一致しない場合、GitHub Desktopはコミットする前に警告を出します。ただしこれは一致しないことを知らせるだけで、正しい方を選んでくれるわけではありません。公開リポジトリにコミットしたとき、Git構成のメールアドレスは誰からでも見える状態になります。個人のアドレスを会社のリポジトリに残さないという観点でも、リポジトリごとの設定は先に入れておく価値があります。

ステップで分ける、混ざらない置き方

設定の意味が分かったら、順番に手を入れます。行き当たりばったりに直すのではなく、置き場所から決めるのが崩れにくい順序です。

• ステップ1: 作業フォルダを用途で分ける。会社用と個人用のリポジトリを同じ親フォルダに並べない。目で見て区別できる階層にしておく
• ステップ2: グローバルのGit構成は、日常でよく使う方に寄せる。[Settings]の[Git]で名前とメールを入れて保存する
• ステップ3: もう一方の用途のリポジトリを開き、[リポジトリの設定...]の[Git 構成]で[ローカルの Git 構成を使用する]に切り替える。クローンした直後にここまで済ませる
• ステップ4: 新しいリポジトリを作る前に、既定のブランチ名を確認する。GitHub Desktopは既定でmainを使い、[Settings]の[Git]の[既定の分岐]タブで変更できる
• ステップ5: プッシュの直前に、ウィンドウ左上の現在のリポジトリ名と、コミット欄の作成者情報を1回だけ見る。習慣化するのはこの1点に絞る

ステップ3を飛ばすと、あとから作成者情報を直しても過去のコミットには残ります。クローンした直後という1回のタイミングで入れてしまうのが、手戻りの少ない進め方です。フック側の事情もここで見ておくとよく、[Git 構成]ペインの[フック]タブでは、シェルからGitフックの環境変数を読み込む設定と、その値をキャッシュする設定を切り替えられます。nvmやrbenvのようなバージョン管理ツールに依存するフックがあるときは、この読み込みを有効にします。

コマンドラインと併用するときに食い違う場所

GitHub Desktopはローカルの Git 構成設定を使って動きます。つまり端末から同じリポジトリを触ったときに見える作成者情報は、アプリで入れた値とそろいます。逆に言えば、端末側で構成を書き換えればアプリの表示も変わるため、どちらが正しいのかを人が覚えておく必要はありません。1つの値を2か所から見ているだけだと考えると混乱が減ります。

食い違いが出やすいのはリモートの指定です。複数のアカウントを使い分ける現場では、SSHの設定ファイルにアカウントごとの別名を書き、リポジトリのリモートURLでその別名を使う方法が広く共有されています。リモートのホスト名をそのまま[email protected]にしておくと、どちらのアカウントで接続するのかが決まりません。別名を使ったリポジトリをGitHub Desktopで開くと、アプリは既に設定されたリモートをそのまま使うため、アプリ側の表示だけでは別名が効いているのかどうか分かりません。

しかし、複数アカウントを使用している場合に[email protected]としてしまうと、「どっちの GitHub アカウントですか？」となってしまいます。 出典: zenn.dev

判断の順番としては、まずアプリでサインイン先と作成者情報をそろえ、それでも権限の問題が残るときにリモートの指定を疑います。逆の順番で調べると、設定ファイルを読み込む時間だけが増えます。GitHub Desktopで[リポジトリ]メニューからリモートURLを確認できるので、疑うときはそこを先に見ます。

ブラウザ側のアカウント切り替えと噛み合わせる

GitHub Desktopの外側にも、切り替えの仕組みがあります。GitHub.comの画面では、右上のプロフィール写真からアカウントスイッチャーを開き、[アカウントを追加]で別のアカウントを足せます。追加すると、その場で新しいアカウントにサインインした状態になり、以後は毎回の再認証なしで行き来できます。

ここで見落としやすい性質が1つあります。複数のアカウントにサインインしてアカウントスイッチャーを使うと、そのセッションはそのパソコンとそのブラウザに残る、という点です。別のパソコンや別のブラウザでGitHubを開いたとき、同じアカウントはそこに追加するまで使えません。つまりブラウザ側の切り替えは、ブラウザという入れ物に紐づいた状態です。

さらに、複数のアカウントにサインインしている状態でGitHub Appのインストールや承認の要求など外部からのリンクをたどると、まずどのアカウントを使うか選ぶよう求められます。シングルサインオンのセッションは、アカウントを切り替えて戻っても保持されるため、IDプロバイダでの認証をやり直す必要はありません。Enterprise Managed Usersを使う企業のメンバーで、セッションの有効期限が切れている場合は、対象のアカウントが淡色表示になります。

つまりデスクトップアプリ側は1つのGitHub.comアカウントを軸に動き、ブラウザ側は複数を並べられるという非対称があります。プルリクエストのレビューや権限の確認をブラウザで行うなら、ブラウザの入れ物をどう分けるかが、そのまま押し間違いの起きやすさに直結します。

押し間違いは記憶ではなく、窓の並びで防ぐ

ここまでの整理で分かるのは、設定を正しく入れても最後に残るのがブラウザ側の状態だという点です。同じブラウザに2つのアカウントを同居させると、GitHubのページはどちらかのアカウントで開きます。レビュー中のプルリクエストと、コミットしているリポジトリの持ち主が食い違っていても、画面はそれを止めません。

この食い違いを構造で消す方法として、Webアプリを用途ごとに別の窓へ置くアプリ集約ブラウザという道具立てがあります。アプリごとに独立したワークスペースを持たせる考え方で、会社用のGitHubと個人用のGitHubを別々の入れ物として並べます。仕組みとしてどう分かれるのかは、ワークスペースの単位を解説したワークスペースに整理があります。通知や窓の扱いを含めた全体像はできることにまとまっています。

どのサービスを同じやり方で置けるのかは、対応の一覧を並べた使えるアプリで確かめられます。GitHubを扱う人にとっては、コマンド操作を同じ窓の並びの中に置けるかどうかも判断材料になるため、内蔵の端末について書かれたターミナルも併せて見る価値があります。既に同種の道具を検討している場合は、機能の線引きを整理したWaveboxとの比較やShiftとの比較が比較の軸を示します。

費用の条件は運用を決める前に確かめておくのが順序で、プランの内訳は料金に載っています。導入前の細かな疑問はよくある質問に集まっています。判断の基準は単純で、押し間違いが起きた場所がGit構成なのか、ブラウザの状態なのかを切り分け、後者なら窓の分け方で解くという整理です。記憶に頼る運用は、忙しい日に必ず崩れます。