【Git】「does not appear to be a git repository」エラーの原因と解決方法|6パターン診断と完全対処ガイド

git pushgit fetchgit pullを実行した時、次のようなエラーが出て先に進めないことがあります。

典型的なエラー出力
$ 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.

このエラーは「指定したリモート(originなど)がGitリポジトリとして認識できない」ことをGitが伝えています。原因は「リモート未登録」「URL間違い」「リポジトリ内にいない」など複数ありますが、診断手順を押さえれば数分で切り分け&解決できます。

この記事では、エラーの6つの原因パターンと対処法を体系的に解説します。git remote -vを起点にした診断フロー、HTTPS/SSHの切替、git initからゼロ構築、WSL/path問題・submodule・mirror cloneといった特殊ケースまで、実務で迷わない形で網羅します。

この記事で学べること

  • エラー発生の6パターン診断フロー(remote未登録/typo/URL間違い/init忘れ/ディレクトリミス/.git破損)
  • git remote -vpwdls -laによる状況切り分け
  • remote addrenameset-urlremoveの使い分け
  • HTTPS/SSH形式の選び方と切り替え方法
  • git initからゼロでGitHubにpushする完全手順
  • WSL/Windowsパス問題・submodule・mirror cloneの特殊ケース対処
  • 同じエラーを出さないための予防策
スポンサーリンク

エラーの正体:どの段階で失敗しているか

「does not appear to be a git repository」はGitがリモート先に接続するより前、「そもそも指定された名前/URLがGitリポジトリを指していない」と判断したときに出ます。似たようなメッセージが複数あるため、まず正確にどのパターンかを見分けましょう。

エラー文 典型的な原因
'origin' does not appear to be a git repository remote名が登録されていない/typo
does not appear to be a git repository(URL直書き時) URLが間違っている/サーバーがGitプロトコルを返さない
fatal: not a git repository (or any of the parent directories) Gitリポジトリ外で実行している(.gitが無い)
Could not read from remote repository. Permission denied 認証エラー(SSH鍵/トークン)——別記事で対処

ポイント:同じ「repository」エラーでも「存在しない/URLが違う」系と「認証が通らない」系は原因が別です。Permission deniedが同時に出るなら「Permission denied (publickey)」エラーの原因と解決方法を先に確認してください。

STEP 0:3コマンドで原因を切り分ける

解決のために最初にやることは診断です。以下の3コマンドでほぼ原因が特定できます。

診断3点セット
# 1. リモートの登録状況を確認
git remote -v
# → 何も出なければ remote未登録
# → orgin など typo がないか?
# → URLは正しいか?

# 2. Gitリポジトリ内にいるか確認
pwd
ls -la | grep "^d.*\.git$"
# → .git ディレクトリが見えるか?
# → 作業したいプロジェクトフォルダに居るか?

# 3. Gitトップディレクトリを確認(サブフォルダに居る場合)
git rev-parse --show-toplevel
# → fatal: not a git repository なら git init していない/違う場所

診断結果から対処へ

診断フロー

  • git remote -v が空 → 原因①:remote未登録 → remote add
  • orgin / origni などtypo → 原因②:名前ミス → remote rename
  • URLが古い・誤り → 原因③:URL誤り → remote set-url
  • not a git repository → 原因④:init忘れ or 原因⑤:ディレクトリミス
  • .gitが壊れている気配 → 原因⑥:.git破損/消失

原因①:リモートが登録されていない

git initでGitリポジトリを作っただけの状態や、git cloneではなく手動でリポジトリ配下を作った場合に起きがちです。git remote -vの出力が空なら、これが原因です。

リモートを追加する
# HTTPS形式(トークンまたはパスワード認証)
git remote add origin https://github.com/USER/REPO.git

# SSH形式(SSH鍵認証)
git remote add origin git@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(upstreamを同時設定)
git push -u origin main

HTTPS と SSH の使い分け

  • HTTPS:ユーザー名+Personal Access Token(PAT)。ファイアウォール制約がある環境、CI/CDで使いやすい
  • SSH:SSH鍵ペアで認証。個人PCでは一度設定すればトークン管理不要。複数アカウント切替にはホストエイリアスが便利
  • 迷うなら個人PCはSSH、CIやWindowsの一時作業はHTTPSが無難
  • origin/upstream概念はoriginとupstreamの違いと使い分けを参照

原因②:リモート名のtypo

orginorigniorigin2など、typoのままリモートを登録してしまったケース。git remote renameで直します。

リモート名を修正する
# 現状確認
git remote -v
# orgin  https://github.com/USER/REPO.git (fetch)  ← typo
# orgin  https://github.com/USER/REPO.git (push)

# 名前を変更
git remote rename orgin origin

# 確認
git remote -v

# push 再試行
git push -u origin main

ポイント:typo防止にはgit cloneを使う、テンプレートからremote addするbashエイリアスを作る、GHEなどエンタープライズ環境ならclone URLをPJのREADMEにコピペ用に記載する、といった運用が有効です。

原因③:URLが間違っている

「リモート名は合っているのにURLが違う」ケース。git remote set-urlで修正します。

URLを修正する
# HTTPS に変更
git remote set-url origin https://github.com/USER/REPO.git

# SSH に変更
git remote set-url origin git@github.com:USER/REPO.git

# push 用・fetch 用で別URLを設定(稀だが可能)
git remote set-url --push origin git@github.com:USER/REPO.git
git remote set-url origin https://github.com/USER/REPO.git

# 確認
git remote -v

よくあるURLの間違い

  • 末尾の.gitを付け忘れ(GitHubは許容されるが他サービスでは拒否される)
  • ユーザー名/組織名の大文字小文字ミス
  • リポジトリをリネームしたのにURLを更新していない
  • プライベートリポジトリを組織に移管した後にURLが変わった
  • HTTPSに不要なgit://スキームを使っている(GitHubは2022年に無効化済)

原因④:git init されていない

ディレクトリにファイルだけ置いてgit initを実行していないケース。.gitフォルダが存在しないため、そもそもGitリポジトリではありません。

.git の有無確認と初期化
# .git の有無を確認
ls -la | grep "\.git$"
# 見つからないなら未初期化

# 初期化から一気にリモート設定・push まで
git init
git branch -M main
git add .
git commit -m "first commit"
git remote add origin https://github.com/USER/REPO.git
git push -u origin main

注意:既存プロジェクトをgit cloneしてきた場合は通常.gitフォルダが自動でできています。.gitが無いなら「cloneできていなかった」「別ディレクトリで作業している」可能性もあるので、pwdで現在地を確認してください。

原因⑤:違うディレクトリで実行している

親ディレクトリや別プロジェクトフォルダでgit pushしてしまうケース。特にgit clone user/repoした後にcd repoを忘れていると発生しがちです。

現在地の確認と移動
# 現在のディレクトリを確認
pwd

# Gitリポジトリのルートを表示(リポジトリ内にいる場合)
git rev-parse --show-toplevel
# → 出力が意図と違うか、fatal: not a git repository なら誤ったディレクトリ

# 正しいリポジトリに移動
cd your-project

# 念のため .git の存在を確認
ls -la | grep "\.git"

# push 再試行
git push -u origin main

起きやすいパターン

  • ターミナルを複数開いていて別タブの作業と混同
  • VS Code統合ターミナルで、プロジェクトを移動した後に開き直していない
  • モノレポで子パッケージ内で個別にGit管理していると勘違い
  • clone後cdせず、親フォルダでgit pushして失敗

原因⑥:.gitフォルダが破損/消失している

まれに.gitフォルダが壊れていてgit pushが通らないケースがあります。削除してしまった、ディスク障害、Windowsの自動バックアップツールが壊したなどが原因です。

.git の状態確認
# .git 内の主要ファイルを確認
ls .git/
# 正常なら config, HEAD, refs/, objects/ などが並ぶ

# fsck で整合性チェック
git fsck --full

# config だけ壊れていないか確認
cat .git/config
# [remote "origin"] セクションがあるか?
復旧アプローチ
# アプローチA: リモートが生きていれば再cloneが最速
cd ..
mv your-project your-project.broken
git clone https://github.com/USER/REPO.git your-project
# 変更があれば broken 側から必要ファイルだけコピー

# アプローチB: config だけ書き直す
# .git/config を開いて [remote "origin"] セクションを追加
# もしくは
git remote add origin https://github.com/USER/REPO.git

# アプローチC: オブジェクトDBが壊れている場合
git fsck
# dangling commit などから復旧できる場合もあるが、基本は再cloneが安全

注意:.git の内部ファイルを不用意に編集/削除すると履歴が失われる可能性があります。作業前に必ず.gitごとバックアップ(cp -r .git .git.bak)し、リモートが無事なら再cloneが最もリスクの低い復旧法です。

ゼロからGitHubにpushする完全手順

「originを一度も設定したことがない」「今の状態を綺麗にやり直したい」——そんなときに使える完全手順です。

STEP 1:GitHubで空リポジトリを作成

GitHub Web でのリポジトリ作成

  1. github.com/new にアクセス
  2. Repository name を入力
  3. Public / Private を選択
  4. 「Initialize this repository with a README」のチェックは外す(既存のローカルをpushするなら空のほうが扱いやすい)
  5. Create repository をクリック

STEP 2:ローカルを初期化してpush

ローカル初期化→push
# プロジェクトフォルダに移動
cd your-project

# Gitリポジトリ初期化
git init

# デフォルトブランチをmainに
git branch -M main

# 最初のコミット
git add .
git commit -m "feat: initial commit"

# リモートを追加(HTTPS or SSH 好きな方)
git remote add origin https://github.com/USER/REPO.git

# 初回push(upstream同時設定)
git push -u origin main

注意:GitHubでREADMEを初期化してしまったうえでローカルをgit initした場合、pushでnon-fast-forwardエラーになります。対処は「git pull origin main --allow-unrelated-historiesで履歴統合」または「GitHub側のREADMEを一度消してから再push」が定石。詳しくはpushで”non-fast-forward”で拒否されたときの解決方法参照。

特殊ケース:WSL・submodule・mirror cloneなど

WSLとWindowsでパスが食い違う

WSL(Windows Subsystem for Linux)上の/mnt/c/...とWindows側C:\...でGitコマンドを交互に使うと、改行コードやパーミッションで.gitが読みづらくなりエラーが起きやすくなります。

WSL環境での対処
# WSL内ではWSLネイティブパスで作業(速い&安全)
mv /mnt/c/dev/your-project ~/dev/your-project
cd ~/dev/your-project
git remote -v

# どうしてもWindows側パスで使うなら safe.directory を追加
git config --global --add safe.directory /mnt/c/dev/your-project

# 改行コード設定を統一
git config --global core.autocrlf input

submodule内でリモートエラー

submoduleのremote再設定
# submodule の初期化
git submodule update --init --recursive

# submoduleに入ってからremote確認
cd path/to/submodule
git remote -v

# 足りなければ同様に remote add
git remote add origin https://github.com/USER/SUBMODULE.git

mirror clone のoriginは扱いが特殊

mirror clone と通常 clone
# mirror clone(全ref含む)
git clone --mirror https://github.com/USER/REPO.git

# mirror の場合 origin は自動で「push先=自分」になるので別名追加
cd REPO.git
git remote add upstream https://github.com/OTHER/REPO.git

# 通常のリモート設定
git remote -v

ホストエイリアス(SSH config)でURL置き換え

~/.ssh/config でホスト分離
# 複数GitHubアカウントを切り替えたい場合
cat >> ~/.ssh/config << "EOF"
Host github-personal
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_personal
Host github-work
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_work
EOF

# remoteでエイリアスを使う
git remote set-url origin git@github-personal:USER/REPO.git

その他確認ポイント

  • プライベートリポジトリにアクセス権限があるか(コラボレータ追加済み?)
  • SAML/SSOが有効な組織では個別のSSOトークン認証が必要なケース
  • 社内プロキシやファイアウォールでHTTPS/SSHが遮断されていないか
  • VPN越しのアクセスでDNS解決が失敗していないか

実践シナリオ

シナリオ① clone忘れで親フォルダから push

正しい場所に移動して再実行
pwd
# /Users/me/projects  ← プロジェクト外

cd your-project
git remote -v   # originが正しく表示されるはず
git push -u origin main

シナリオ② 既存プロジェクトを一気にGitHubにpush

init→push の定番
cd your-project
git init
git branch -M main
git add .
git commit -m "feat: initial commit"
git remote add origin git@github.com:USER/REPO.git
git push -u origin main

シナリオ③ リポジトリがリネームされた

URLだけ新しくする
git remote set-url origin https://github.com/USER/NEW_NAME.git
git remote -v
git pull
git push

シナリオ④ fork開発で upstream も追加したい

origin + upstream
# origin は自分のfork、upstream は本家
git remote add upstream https://github.com/UPSTREAM_OWNER/REPO.git
git remote -v
# origin    ... (fetch/push)
# upstream  ... (fetch/push)

# 本家の最新を取り込む
git fetch upstream
git rebase upstream/main
# push は自分のforkへ
git push origin main

詳細はoriginとupstreamの違いと使い分け完全ガイドを参照。

やってはいけない落とし穴

remote addを2回実行して「already exists」で止まる

既にoriginが登録されているのにgit remote add origin ...を再実行するとerror: remote origin already existsが出ます。URLを変えたいだけならgit remote set-url origin NEW_URL、一度消してやり直したいならgit remote remove originしてから再追加します。

.gitを勢いで削除して履歴を飛ばす

「Gitの状態が変だから.gitを消せばいい」と考えてrm -rf .gitすると、ローカル履歴が完全に失われます。リモートに同じ履歴が残っていれば再cloneで回復できますが、ローカル固有のコミット(未push)は取り戻せません。.gitの操作前は必ずcp -r .git .git.bakでバックアップを。

URLの末尾 .git を省略して他サービスで拒否される

GitHubは.git省略を許容しますが、GitLab自己ホスト・Bitbucket・Gitea等ではサービスや設定によって拒否されます。基本的には.gitを付けるのを推奨します。ブラウザからコピペするURL(github.com/user/repo)に.gitを追加する癖を付けましょう。

origin を消して push先を失う

git remote remove originで消したあと、改めてremote addし忘れると以後のpushで本記事のエラーが再発します。消す操作はrename/set-urlで代替できないか先に検討を。

Permission deniedと混同して remote を疑う

「does not appear to be a git repository」と「Permission denied」は別のエラーです。権限系エラーはSSH鍵/トークン・コラボレータ権限の問題なので、remote設定をいくらいじっても解決しません。SSH系のトラブルは「Permission denied (publickey)」エラーの原因と解決方法を参照してください。

よくある質問

Qgit remote add origin で「already exists」と出る
Aoriginが既に登録されています。URLを変えたいだけならgit remote set-url origin NEW_URL、一度消してから追加したいならgit remote remove origingit remote add ...の順で実行します。
Qpush で rejected / non-fast-forward が出る
A別のエラーです。リモートがローカルより先行しているためgit pull --rebase origin mainで取り込んでから再push、または個人ブランチならgit push --force-with-leaseで解決します。詳細は“non-fast-forward”で拒否されたときの解決方法を参照。
QPermission denied (publickey) が同時に出る
ASSH鍵がGitHubに登録されていない、または鍵のパスが認識されていません。一時的にHTTPS形式に切り替えるか、「Permission denied (publickey)」エラーの原因と解決方法で鍵登録手順を確認してください。
Qgit clone したのに同じエラーが出る
Acloneすると通常originは自動設定されます。このエラーが出るなら(1) clone後にcdでリポジトリに入っていない、(2) 別ディレクトリで操作している、(3) .gitが消えた、のいずれかの可能性が高いです。pwdgit remote -vで状態を確認しましょう。
QHTTPSからSSHに変えたい/逆にしたい
Agit remote set-url origin NEW_URLでURLを書き換えるだけです。HTTPS→SSHはgit@github.com:USER/REPO.git、SSH→HTTPSはhttps://github.com/USER/REPO.gitに変更します。
Qモノレポで複数リポジトリを扱いたい
A1リポジトリ=1.gitが原則です。サブプロジェクトを別リポジトリとして管理するならsubmoduleやgit subtree、あるいはpnpm workspace・yarn workspaces等のパッケージマネージャ機能と組み合わせます。
Qoriginとupstreamは何が違う?
Aoriginは自分のクローン元(通常はfork or 自リポジトリ)、upstreamはfork開発における本家を指す慣習的な名前です。詳しくはoriginとupstreamの違いと使い分けを参照。

関連記事

まとめ

  • 「does not appear to be a git repository」は「リモートがGitリポジトリとして認識できない」合図
  • まずgit remote -vpwdgit rev-parse --show-toplevelの3つで診断
  • 原因は6パターン:①未登録/②typo/③URL誤り/④init忘れ/⑤ディレクトリミス/⑥.git破損
  • 対処はremote addrenameset-urlgit initcd/再clone
  • HTTPSとSSHは用途で使い分け、切替はset-urlで一行
  • Permission deniedは別系統のエラーなので別途対処
  • WSL/submodule/mirror/SSH configといった特殊ケースも診断フローは同じ

このエラーに遭遇しても、診断フローに沿ってgit remote -vから始めれば、数分で原因と対処が特定できます。「何となくpushできないから.git消す」「force pushで乗り切る」といった乱暴な対応をせず、状態を正確に読んで一つずつ片付けるのが遠回りに見えて最短です。運用面ではgit cloneで始める・git init後すぐにremote addする、命名規則(originupstream)を徹底する、といった習慣で予防できます。