このエラーは「指定した相手をGitリポジトリとして参照できない」場面の記録です。ローカルのnot a git repository、SSH認証失敗、GitHubのRepository not foundは別の情報なので、実行したコマンドと前後のメッセージを一緒に確認します。理由を一つに決めてgit initやpushへ進みません。

1. 信頼できる作業場所で、読取りから確認する

次は既知のローカルリポジトリで実行するPOSIX sh用の読取り例です。originがなければURL取得で止まるため、その場合は未設定/別名のremoteを確認します。出力には私的なパスや、誤って保存されたURLの資格情報を含む可能性があります。画面や生ログをそのまま公開しないでください。未知のリポジトリの設定/helper/hooksを安全に検査するsandboxではありません。

#!/bin/sh
set -eu
# Run only in a trusted local repository. Output may contain private URLs/paths.
git rev-parse --is-inside-work-tree
git rev-parse --is-bare-repository
git remote
git remote get-url --all origin
git remote get-url --push --all origin
# Exit 1 means no matching configured value; other errors must remain failures.
git config --includes --show-origin --show-scope --get-all http.sslVerify || test "$?" -eq 1

fetch用とpush用のURLは異なることがあります。insteadOf/pushInsteadOf等の書換え、複数URL、設定元も確認し、表示された一つだけで全操作の送信先を保証しません。.gitはディレクトリだけでなくworktree等でファイルの場合や、bareで作業ツリーを持たない場合もあります。lsで.gitが見つからないだけで新規作成しません。

2. 接続先の確認後に参照一覧を取得する

次は通信を伴う確認です。自分に許可されたURL/経路であることを確認し、社内proxy/VPNを無断で迂回しません。TLS/SSHのホスト確認を維持し、実資格情報をURLへ埋め込みません。

#!/bin/sh
set -eu
# This contacts the configured target. Confirm the URL, route and permissions first.
# Listing refs does not establish push rights, HEAD checkoutability or branch existence.
git ls-remote --symref origin HEAD

ls-remoteは参照の読取りで、push/初回commit/新しい履歴の公開をする例ではありません。ただし認証helperの起動/資格情報の利用や相手側のアクセスログ等はあり得ます。設定済みの認証方法を先に確認してください。成功しても書込み権限や特定branchの存在は保証しません。空のbareへ接続成功して出力が空の場合もあり、--exit-codeで指定参照がない場合の2と、接続自体の失敗を区別します。

3. 直す対象を間違えない

確認結果	次に確認する対象
作業場所が違う	既存のcheckout/worktreeの場所。無関係な場所でinitしない
remote名/URLが違う	所有者が案内したURL、既存設定/送信先。変更前の値を非公開で控える
認証できない/権限がない	選択したアカウント、招待/対象リポジトリ、資格情報の期限/種類、必要な組織承認
経路/TLSエラー	承認済みproxy/VPN、名前/時刻/証明書チェーンと信頼ストア

新しいSSH鍵やPATを作る前に、既存の対象アカウント/鍵/権限を確認します。SSHの認証成功と、対象リポジトリへの読取り/書込み許可は別です。既定ファイルへの鍵生成、SSH設定への追記、credential.helperのglobal変更をこのエラーの通常手順として行いません。PATは方式に応じて対象と必要権限へ限定し、無条件にclassicのrepo scopeを追加しません。

TLS検証を止めずproxyと区別する

globalなhttp.sslVerify=falseは自己署名証明書だけを許可する設定ではありません。HTTPSの証明書検証を広く無効化し得るため、暫定回避にも推奨しません。対象ホスト/URL単位の設定や環境変数等も関係するので、単に一つの値を消せば全設定が元通りになるとは扱いません。確認済みCAと対象の名前/チェーンを直し、未知のCAは取り込みません。

Git設定のhttp.proxyはHTTPSのproxyにも使われ、https.proxyという任意キーを書けることとGitがその値を通信に使うことは別です。https_proxy等の環境変数とも区別します。git -c http.proxy= pushはTLS検証の変更ではなく、その呼出しのproxy設定に関係し、push自体は書込み操作です。疎通確認の代替にせず、URL/remote別設定や環境の優先関係はGitのproxy設定も参照してください。

pingの成功/失敗やcurlのHTTP応答だけでGitの参照/認可の成否を保証しません。ブラウザで閲覧できるアカウントと、CLIが使う資格情報も別に確認します。実接続の修正はこの隔離検証では行っていません。

旧記事の例と個別の注意

旧コード/表/章は次に保持しています。危険な操作の前には個別の訂正を置き、元v2の黒いエラー表も末尾へ補っています。古いキー発行/全体設定/公開操作をそのまま実行する案内ではありません。

旧例の注意：旧要点のinit/remote追加/認証への直結は推奨しません。ローカルとリモートのエラーを区別し、作業場所と許可された参照先を先に読み取ります。

この記事の要点

git clone / push / pull / fetch 時に出る基本エラー「does not appear to be a git repository」 主な原因: ① そもそも .git ディレクトリが無い場所で実行 / ② リモート URL のタイポ / ③ SSH 鍵未登録 / ④ git remote add origin 未実行 対処: git status / git remote -v で状態確認 → git init / git remote add origin <url> プライベートリポジトリで存在しないように見える場合は権限不足の可能性 → PAT / SSH 鍵で認証 社内 Git サーバの場合はVPN 未接続や DNS 解決失敗もよくある

このエラーの概要

git コマンドを実行したときに表示される、最も基本的なエラーの一つです:

旧例の注意：複数の別エラーを並べた記録です。not a git repository、does not appear、publickeyやRepository not foundを同じ原因と扱わず、書込み操作を診断の第一歩にしません。

# パターン1: カレントが git 管理下じゃない
$ git status
fatal: not a git repository (or any of the parent directories): .git

# パターン2: リモート操作
$ git push origin main
fatal: 'origin' does not appear to be a git repository
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

# パターン3: クローン時
$ git clone git@github.com:user/typo-repo.git
Cloning into 'typo-repo'...
ERROR: Repository not found.
fatal: Could not read from remote repository.

# パターン4: SSH 認証失敗
$ git pull
git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.

コマンドの実行場所と参照先、認証と認可を分けて確認します。リモート先を読めないエラーを、手元でinitするだけで直せるとは扱いません。

原因の切り分けフロー

旧例の注意：旧フローのinit/新鍵/トークン更新は確認前に実行しません。.gitの形やbare、接続先と認証/認可、実経路を分けます。

シナリオ	切り分けコマンド	対処
ローカルが git 管理下でない	ls -la .git	git init（対処1）
origin 未設定	git remote -v	git remote add origin URL（対処2）
URL タイポ	git remote get-url origin	git remote set-url（対処3）
SSH 鍵未登録	ssh -T git@github.com	鍵登録（対処4）
権限不足	ブラウザで該当 URL を開く	招待 / トークン更新（対処5）
VPN/プロキシ	ping git.internal / curl -I URL	VPN 接続（対処6）

対処1: ローカルディレクトリが git 管理下でない

旧例の注意：grepで.gitが見えないだけで存在しないと断定できません。新規init/add/commitや外部cloneは既存内容/公開範囲へ影響するため、このエラーの自動修復として実行しません。

# まず現在地と .git の有無を確認
pwd
ls -la | grep .git

# 親ディレクトリにも .git が無いか
git rev-parse --show-toplevel
# fatal: not a git repository (or any of the parent directories)
# → どこにも無い

# 新規 git リポジトリにする場合
git init
git add .
git commit -m "Initial commit"

# 既存リポジトリをクローンしたい場合
cd ..
git clone https://github.com/user/repo.git
cd repo

対処2: origin が未設定 / 別名で登録されている

旧例の注意：originを作る前に既存remote/URL/対象を確認します。pushは相手の履歴を更新し得る操作で、疎通確認のための通常手順にはしません。

# リモート一覧
git remote -v
# (何も表示されない → origin 未設定)

# origin 追加
git remote add origin https://github.com/user/repo.git

# 確認
git remote -v
# origin  https://github.com/user/repo.git (fetch)
# origin  https://github.com/user/repo.git (push)

# 初回 push（上流ブランチ設定込み）
git push -u origin main

対処3: リモート URL のタイポ修正

旧例の注意：set-url/remove/protocol切替は設定変更です。所有者が示すURLとfetch/push用URL・書換え設定を確認し、元の情報を非公開で控えてから必要な変更だけ行います。

# 現在の URL
git remote get-url origin

# URL を書き換え
git remote set-url origin git@github.com:correct-user/correct-repo.git

# 別名リモートを追加
git remote add upstream https://github.com/original/repo.git

# 不要なリモート削除
git remote remove old-origin

# HTTPS ↔ SSH 切替
# HTTPS → SSH
git remote set-url origin git@github.com:user/repo.git
# SSH → HTTPS
git remote set-url origin https://github.com/user/repo.git

対処4: SSH 鍵が未登録

Permission denied (publickey) が併発する場合:

旧例の注意：既定名の鍵生成/agent起動/SSH設定追記は検証のために実行していません。既存の鍵を上書きせず、CIのpassphraseを一律に空へしません。ホスト鍵を確認し、SSH認証成功とリポジトリ認可を分けます。

# 既存鍵を確認
ls -la ~/.ssh/

# 無ければ生成 (ed25519 推奨)
ssh-keygen -t ed25519 -C "you@example.com"
# 保存先はデフォルト Enter で OK
# passphrase は CI なら空でも可

# 公開鍵を GitHub Settings → SSH and GPG keys に貼り付け
cat ~/.ssh/id_ed25519.pub

# ssh-agent に追加
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

# 疎通テスト
ssh -T git@github.com
# Hi <username>! You've successfully authenticated, ...

# SSH 設定で複数アカウント使い分け
cat >> ~/.ssh/config <<'EOF'
Host github.com-work
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_work
EOF

対処5: HTTPS / PAT 認証エラー

GitHubへのHTTPS認証では個人アカウントのパスワードとPAT等の資格情報を区別します。利用中の認証方法/アカウント/期限/対象権限を確認し、次の旧操作を一括実行しません。

旧例の注意：global helper変更/トークン再発行/pushを無条件に行いません。URLへのUSER:TOKEN埋込みは非推奨というだけでなく使用しないでください。PATの種類/対象/期限・必要な権限/組織承認を確認し、classicのrepoを一律に付けません。

# git の credential 設定
git config --global credential.helper cache
# またはストア永続化（macOS）
git config --global credential.helper osxkeychain

# 初回 push 時にユーザー名とトークン (パスワードの代わり) を入力
git push
# Username: your-github-username
# Password: ghp_xxxxxxxxxxxxxxxxxxxx  ← PAT を入力

# URL に直接埋め込む（非推奨：履歴に残る）
git remote set-url origin https://USER:TOKEN@github.com/user/repo.git

# Personal Access Token 作成
# GitHub → Settings → Developer settings → Personal access tokens
# スコープ: repo (private 利用時) / public_repo

対処6: 社内 Git サーバ / VPN / プロキシ

旧例の注意：http.sslVerify=falseは自己署名だけを許可する設定ではありません。HTTPS検証を広く無効化するため使いません。Gitのhttps.proxyキーと環境変数https_proxyを区別します。-c http.proxy= pushはTLS検証変更ではなくproxy設定に関係し、pushは書込みなので診断例にしません。ping/curlの結果もGit認可の証明ではありません。

# DNS 解決確認
nslookup git.internal.example.com

# 疎通確認
curl -I https://git.internal.example.com
ping git.internal.example.com

# VPN 接続必要なら接続後に再試行

# プロキシ経由（社内 PC）
git config --global http.proxy http://proxy.example.com:8080
git config --global https.proxy http://proxy.example.com:8080
git config --global http.sslVerify false   # 自己署名のみ（非推奨）

# 一時的に無効化
git -c http.proxy= push

初心者がハマる典型パターン

旧例の注意：旧表のInitialize Repositoryも既存の作業場所を確認せず選びません。Windowsの大小文字はファイルシステム/接続先等にも依存し、一律に同じ挙動と断定しません。

状況	原因	対処
サブディレクトリで git init したのを忘れている	親ディレクトリでコマンド実行	cd でリポジトリ内へ
VS Code で「フォルダを開く」したが git 管理外	.git が無い	Source Control → Initialize Repository
クローン直後にディレクトリ外で git status	カレントが repo の親	cd repo
Windows でパスの大文字小文字	git は大小区別する	正しい URL を貼り直し

FAQ

Q: git clone したのにすぐ「not a git repository」と言われる
A: 外で実行した可能性はありますが、それだけに断定しません。目的のcheckout/worktree/bareと実行コマンドを確認し、既存リポジトリの正しい場所から調べます。

Q: 自分は read 権限あるはずなのに「Repository not found」
A: 参照先/選択アカウント、招待、資格情報の種類/期限/対象と組織の承認等を確認します。必ず再発行やclassicのrepo追加で解決するとは扱いません。

Q: WSL から Windows の git に切り替えたら毎回認証要求
A: Git実体と認証helperの実際の導入場所/対応版・共有方針を確認します。掲載された旧パスを全環境共通とせず、global設定へそのまま上書きしません。

元v2のエラー記録

元例の注意：元の黒い表を保持します。URLや接続情報が違う場合だけでなく、認証/認可や経路も別に確認し、存在しないと即断しません。

fatal: '～' does not appear to be a git repository fatal: Could not read from remote repository.

確認範囲と関連情報

2026年10月26日確認。Linux Git 2.47.3の隔離repoで新しい読取例/欠けたremote/空bare/URL書換えとfetch/push URLを確認しました。既存のproxy教材も同じローカルloopback検体で再検査し、TLS検証を停止せず通信を確認しました。実GitHub/SSH/PAT/SSO/VPN・ホスト鍵/本番経路・全Git版や認可は未検証。所有者のglobal設定/鍵や外部remoteを書き換えていません。

Gitのエラー一覧から子ページを選択できます。Git親ページとproxy設定も参照してください。

公式資料：Git設定/URL書換え/HTTPS、ls-remoteと終了状態、GitHubの存在/認証/権限の切り分け。