GitHubからGitLabまで、複数のリポジトリを抱える悩み
会社用のGitLabと個人用のGitHubを並行して使うのは、エンジニアにとってよくある光景です。しかし、そこに複数のクライアントのアカウントが加わると、権限の設定ミスで思わぬトラブルに見舞われることがあります。最も多いのは、コードをプッシュする際の403 Forbiddenエラーです。さらに悪いことに、会社のプロジェクトに個人のメールアドレスでコミットしてしまい、Gitの履歴が非専門的に見えてしまうこともあります。
以前、私はリポジトリをクローンする際にHTTPSを使っていました。しかし、プッシュのたびにユーザー名やパーソナルアクセストークン（PAT）を入力するのは非常に面倒でした。SSH configに移行してからは、毎日の作業で少なくとも10〜15分の時間を節約できています。設定した「エイリアス（別名）」に基づいてシステムが自動的にアカウントを識別してくれるため、開発環境を完全に分離することができます。
問題の本質：なぜSSH Configが必要なのか？
デフォルトでは、SSH経由でGitHubに接続する際、PCは認証のために~/.ssh/id_rsaファイルを探します。しかし、GitHubでは1つの公開鍵を2つの異なるアカウントで共有することはできません。たとえ2つの個別の鍵を作成したとしても、SSHクライアントはどちらも同じホストであるgithub.comを指しているため、適切な鍵を自動的に選択するほど賢くはありません。
SSH Configは、エイリアス（別名）を作成することでこの問題を解決します。github.comを直接使う代わりに、github-personalやgithub-workといった名前を使用します。このエイリアスのおかげで、PCはサーバーに対して提示すべき適切な「鍵」を正確に判断できるようになります。
詳細な設定手順
ステップ1：個別のSSHキーを作成する
1つの鍵をすべてに使い回すのは避けましょう。私のアドバイスとしては、アカウントごとに専用のキーペアを作成することをお勧めします。従来のrsaよりも安全で軽量なed25519アルゴリズムを優先的に使用しましょう。
# 個人用アカウントのキー
ssh-keygen -t ed25519 -C "[email protected]" -f ~/.ssh/id_ed25519_personal
# 会社用アカウントのキー
ssh-keygen -t ed25519 -C "[email protected]" -f ~/.ssh/id_ed25519_work既存のキーを上書きしないよう、-fパラメータを使って異なるファイル名を指定することを忘れないでください。
ステップ2：公開鍵をGitHub/GitLabに登録する
.pubファイルの内容をコピーして、ブラウザのSSH設定（Settings）セクションに貼り付ける必要があります。catコマンドや、macOSならpbcopyを使って素早くコードを取得できます。
cat ~/.ssh/id_ed25519_personal.pub
# コードをすべてコピーして、個人のGitHubアカウントに貼り付けますステップ3：SSH Configファイルの設定
ここが最も重要なステップです。以下のコマンドを使って、~/.ssh/configファイルを開くか、新規作成します。
nano ~/.ssh/config次に、以下のテンプレートに従って設定を入力します。
# 個人用GitHub
Host github.com-personal
HostName github.com
User git
IdentityFile ~/.ssh/id_ed25519_personal
# 仕事用GitHub
Host github.com-work
HostName github.com
User git
IdentityFile ~/.ssh/id_ed25519_work
# 会社用GitLab
Host gitlab.com-work
HostName gitlab.com
User git
IdentityFile ~/.ssh/id_ed25519_workここで、Hostは自分で決めた識別名、HostNameはサーバーの実際のアドレス、IdentityFileは対応する秘密鍵へのパスを指します。
ステップ4：実際のクローンとプッシュの方法
最も間違いやすいのがこのステップです。GitHubから取得した SSHリンクをそのままコピーするのではなく、ホスト部分をconfigファイルで設定した名前に書き換える必要があります。
例えば、元のリンクが[email protected]:user/repo.gitの場合、
次のようなコマンドでクローンします：
git clone [email protected]:user/repo.gitすでにプロジェクトがローカルにある場合は、リモートURLを更新して、最初からやり直さなくて済むようにします。
git remote set-url origin [email protected]:user/repo.gitGit Configで情報の混同を防ぐ
SSH configはアクセスの問題を解決してくれますが、user.nameやuser.emailを自動的に修正してくれるわけではありません。不注意で会社のコミット履歴に個人のアカウント名が表示されてしまうと、非常に不自然な印象を与えてしまいます。
私のアドバイスは、メールアドレスをグローバル（--global）で設定しないことです。代わりに、プロジェクトごとに個別に設定しましょう。
git config user.name "Your Name"
git config user.email "[email protected]"より高度な管理をしたい場合は、.gitconfigファイルのincludeIf機能を調べてみてください。これにより、プロジェクトのフォルダ（例：~/work/なら会社用、~/personal/なら個人用）に基づいてメールアドレスを自動的に切り替えることが可能になります。
実践的なヒントと注意点
このワークフローを開発チーム全体に導入したところ、非常に安定して動作しています。トラブルを避けるための3つの注意点をまとめました：
- 接続テスト： 開始前に
ssh -T [email protected]コマンドを試してください。「Hi username!」というメッセージが表示されれば成功です。 - SSHエージェント： 再起動後にPCがキーを「忘れる」ことがあります。認証エラーが発生した場合は、
ssh-addコマンドでエージェントにキーを追加することを忘れないでください。 - ホスト名の設定： 短く判別しやすい名前を選びましょう。ただし、Webサイトへのアクセスに影響を与えないよう、実際のドメイン名と完全に一致させるのは避けてください。
SSH configの設定にはわずか5分しかかかりませんが、得られる安心感は絶大です。権限エラーに悩まされたり、コードをプッシュするたびにどのアカウントを使っているか不安になったりすることはもうありません。
設定で困ったことはありませんか？下のコメント欄でお気軽にご質問ください。すぐにお答えします。
