GitHubのリポジトリURLの調べ方｜cloneに使う住所はどこにあるか

GitHubのリポジトリURLを聞かれて、ブラウザのアドレス欄をそのままコピーして渡したら、相手のcloneが通らなかった。逆に、手順書に書かれたURLで git clone を打ったら認証を求められ、アカウントのパスワードを入れても弾かれた。github リポジトリ url の調べ方がややこしく見えるのは、同じリポジトリに用途の違う住所が何本もぶら下がっていて、画面のどこを見るかで取れる住所が変わるからです。どの住所が何のためのものかを一度並べてしまえば、次からは画面を開かずに組み立てられます。

同じリポジトリに、用途の違うURLが何本もある

「リポジトリのURLを教えて」という依頼が噛み合わないことがあるのは、言葉のほうが1つしかないのに、実体が5系統あるからです。

1つ目は、ブラウザで開くためのURLです。https://github.com/OWNER/REPOSITORY の形で、アドレス欄にそのまま出ています。人に見せる、issueのコメントに貼る、READMEから参照する、という用途ならこれで足ります。

2つ目は、HTTPS形式のcloneURLです。末尾に .git が付いた https://github.com/OWNER/REPOSITORY.git で、git clone に渡すのはこちらです。3つ目はSSH形式のcloneURLで、[email protected]:OWNER/REPOSITORY.git という形になります。ホスト名のあとがスラッシュではなくコロンで、スキーム名も付きません。この形をブラウザのアドレス欄に入れても何も開きません。

4つ目は、GitHub CLIに渡す指定です。これはURLの形をしておらず、OWNER/REPOSITORY という短い文字列だけで足ります。5つ目は、GitHub Pagesで公開したサイトのURLで、https://OWNER.github.io/REPOSITORY/ という別系統の住所になります。リポジトリを置いた場所と、そこから生成されたサイトの場所は別のものです。

つまり「URLを送って」と言われたときに正解が揺れるのは、送り先が読む人なのか、コマンドなのかが決まっていないからです。この分け方を先に確かめると、以降の作業はほぼ機械的になります。

Gitにpushしたリポジトリを他の人へ共有したい時｡ リポジトリのURLを送って！と言われますね 出典: qiita.com

画面から取る手順は、Codeボタンの下にある3つのタブ

GitHubの画面から取る手順は短く、公式の説明もそのまま短いままです。リポジトリのページを開き、ファイル一覧の上にある Code をクリックします。すると小さなパネルが開き、そこに HTTPS、SSH、GitHub CLI という3つのタブが並びます。

タブを切り替えると、下に表示される文字列が入れ替わります。HTTPSのタブを選べばHTTPS形式のcloneURL、SSHのタブを選べばSSH形式、GitHub CLIのタブを選べば gh repo clone から始まるコマンドが、そのまま貼り付けられる形で出てきます。右側のコピーアイコンを押せばクリップボードに入るので、手で打ち直す必要はありません。GitHubの公式手順は、この「コピーアイコンをクリックする」という操作を明示しています。

ここで注意したいのは、タブの選択が記憶されることです。前に誰かがSSHのタブを選んだ画面を見ていると、HTTPSのURLが欲しいのにSSHの文字列をコピーしてしまいます。取ったURLが git@ で始まっているかどうかを、貼り付けた直後に一度見る習慣を付けておくと、この取り違えは起きません。

もう1つ、Code のパネルにはダウンロード用の項目も同居しています。履歴の要らない一度きりの参照ならZIPで落とすほうが早く、そのときはURLを調べる必要すらありません。cloneが必要なのは、履歴を持ち歩きたいときと、あとで自分の変更を送り返したいときだけです。

HTTPSとSSH、どちらのcloneURLを選ぶか

2つの形式は、通す経路と認証の材料が違います。機能の優劣ではなく、どちらの準備が済んでいるかで決まります。

見る点	HTTPS	SSH
URLの形	https://github.com/OWNER/REPOSITORY.git	[email protected]:OWNER/REPOSITORY.git
事前の準備	不要	鍵の生成と公開鍵の登録
認証に使うもの	personal access token	秘密鍵とパスフレーズ
毎回の入力	資格情報の保存をしなければ都度	鍵を登録すれば不要
向いている場面	他人の機械、一時的な環境、外向きの通信が絞られた回線	自分が長く使う常用機

HTTPSで詰まる人がいちばん多いのは、認証の材料を間違えるところです。GitHubの公式文書は、Gitがパスワードの入力を求めてきたらpersonal access tokenを入力すると書いており、より安全な認証方法を優先するためにパスワードベースの認証は削除された、と明記しています。つまりアカウントのログインパスワードを打ち込んでも通りません。ここを知らないまま何度も打ち直して、URLが間違っていると疑ってしまうのがよくある回り道です。

SSHを選ぶ場合は、URLよりも先に鍵の準備が必要です。鍵を作り、公開鍵をアカウントに登録し、手元の秘密鍵が読める状態になっていて初めて [email protected]: 形式のURLが通ります。この前提が揃っていれば、以降は入力を求められなくなるので、毎日触るリポジトリほど得になります。SSHの鍵と証明書の扱いに慣れているなら、迷う理由はほとんどありません。

逆に、他人のMacで一度だけ作業する、共有端末で作業する、外向きの通信が絞られた回線にいるといった場面では、鍵を置いていくことのほうが面倒になります。その場合はHTTPSを選び、作業が終わったら保存した資格情報を消すほうが後始末が軽く済みます。

手元のリポジトリからURLを調べる。gitが覚えている

すでにcloneしてあるリポジトリなら、URLを探しにブラウザを開く必要はありません。Gitがリモートの住所を設定として持っているので、そこから読み出せます。

よく使われるのが git remote -v です。Gitの公式文書は、このオプションを「リモート名のあとにURLを表示する」ものだと説明し、remote とサブコマンドの間に置かなければならないという注意まで付けています。表示は1つのリモートに対して2行になり、取得用と送信用がそれぞれ出ます。2行が別の住所になっている状態もあり得るので、片方だけを見て判断しないことが大切です。

1本だけ欲しいときは git remote get-url origin のほうが素直です。公式文書はこのサブコマンドを「リモートのURLを取得する」ものと説明し、既定では最初のURLだけを出す、--push を付けると送信側を、--all を付けるとすべてを並べると書いています。スクリプトに組み込むなら、余分な装飾が付かないこちらが扱いやすくなります。

設定の実体はリポジトリの中の設定ファイルにあります。見えている文字列がどこから来ているのかを確かめたいときは、そのファイルを開いて [remote "origin"] の項目を読むのがいちばん誤解がありません。3つの経路はすべて同じ設定を見ているので、どれを使っても答えは一致します。

Gitの公式文書には、取得用と送信用のURLは別々に設定できるものの、同じ場所を指していなければならないという但し書きもあります。片方だけを書き換えて、もう片方が古いままになっている状態は、あとで原因の見えにくい失敗を生みます。

取り違えたときに起きることと、直し方

URLを取り違えた結果はいくつかの形で表に出ます。HTTPSでcloneしたあと毎回tokenを求められる、SSHでcloneしたのに鍵を置いていない機械に持ち込んで通らない、リポジトリ名を変えたあとも古い名前を指したまま、organizationへ移したあとに前の所有者を指したまま、といった具合です。

いずれの場合も、cloneし直す必要はありません。リモートの住所だけを書き換えれば済みます。公式文書が示す構文は git remote set-url [--push] <name> <newurl> [<oldurl>] で、説明には、<oldurl> に一致するURLがなければエラーになって何も変わらない、と書かれています。何も変わらないという挙動はここでは安全側で、書き換えたつもりで別のリモートを壊してしまう事故が起きにくくなっています。

--push を付ければ送信側だけを書き換えられます。--add は既存のURLを置き換えるのではなく追加し、--delete は正規表現に一致するURLを削除します。公式文書は、送信用ではないURLをすべて消そうとするのはエラーになる、とも書いています。使う頻度が高いのは引数なしの置き換えで、残りは必要になったときに調べれば足ります。

書き換えたあとは、もう一度 git remote -v で取得用と送信用の両方を見て、狙った住所に揃っているかを確かめます。ここを飛ばすと、手元では通るのに他の人の環境では通らない状態を作り込むことになります。

人に渡すURLは、あらかじめ1つに決めておく

手順書やREADMEを書くときは、どの形式を載せるかを先に決めておくほうが親切です。読む人向けの参照リンクならブラウザのURL、誰の環境でも通したい手順書ならHTTPS形式、自分の常用機の作業メモならSSH形式、という割り振りが素直な形になります。

混ぜないことのほうが大事です。同じ文書の中で、ある箇所はHTTPS、別の箇所はSSHで書かれていると、読んだ人はどちらかで詰まります。特に、SSHの鍵を登録していない人に [email protected]: の形を渡すと、URLが間違っているのか自分の環境が足りないのかを切り分けるところから始めさせてしまいます。

外部に配る文書なら、HTTPS形式を載せて、SSHを使いたい人は自分で読み替えてくださいと1行添える形が無難です。読み替えは規則的で、ホストの前後をコロンに直すだけなので、慣れた人にとっては手間になりません。

フォルダとターミナルとAIを同じ窓に置くと、この確認が1手で済む

ここまでの作業を分解すると、やっていることは3つしかありません。リポジトリのフォルダを見つける、設定ファイルかコマンドで住所を読む、必要なら書き換える。それだけの作業に、Finderのウインドウとターミナルのウインドウとブラウザのタブを行き来しているのが、実際にかかっている時間の大半です。

フォルダとターミナルとAIが同じ窓にある状態なら、目的のフォルダを選んだ時点でそこがコマンドの実行場所になり、設定ファイルの中身も同じ画面で読めます。何ができる道具なのかはできることにまとめてあり、既存のファイル管理アプリとの違いは他のファイル管理との比較で整理しています。

AIを同じ窓に置く意味は、URLを組み立ててもらうことではありません。組み立ては規則で決まるので人がやったほうが速く、そこを任せると誤りが混ざります。任せる価値があるのは、複数のリポジトリのリモート設定を並べて食い違いを指摘させる、といった目で追うのが面倒な確認のほうです。

Macの外から続きを触りたい場面についてはiPhone・iPadから続きをに、費用の考え方は料金に、導入前に多い疑問はよくある質問にまとめてあります。日本語以外の環境で使う場合の対応範囲は対応言語で確かめられます。