git push・git fetch・git 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 -v・pwd・ls -laによる状況切り分けremote add・rename・set-url・removeの使い分け- HTTPS/SSH形式の選び方と切り替え方法
git initからゼロでGitHubにpushする完全手順- WSL/Windowsパス問題・submodule・mirror cloneの特殊ケース対処
- 同じエラーを出さないための予防策
エラーの正体:どの段階で失敗しているか
「does not appear to be a git repository」はGitがリモート先に接続するより前、「そもそも指定された名前/URLがGitリポジトリを指していない」と判断したときに出ます。似たようなメッセージが複数あるため、まず正確にどのパターンかを見分けましょう。
ポイント:同じ「repository」エラーでも「存在しない/URLが違う」系と「認証が通らない」系は原因が別です。Permission deniedが同時に出るなら「Permission denied (publickey)」エラーの原因と解決方法を先に確認してください。
STEP 0: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
orgin・origni・origin2など、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で修正します。
# 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 の有無を確認 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 内の主要ファイルを確認 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 でのリポジトリ作成
- github.com/new にアクセス
- Repository name を入力
- Public / Private を選択
- 「Initialize this repository with a README」のチェックは外す(既存のローカルをpushするなら空のほうが扱いやすい)
- Create repository をクリック
STEP 2:ローカルを初期化して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ネイティブパスで作業(速い&安全) 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 の初期化 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(全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置き換え
# 複数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
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
シナリオ③ リポジトリがリネームされた
git remote set-url origin https://github.com/USER/NEW_NAME.git git remote -v git pull git push
シナリオ④ fork開発で 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)」エラーの原因と解決方法を参照してください。
よくある質問
git remote set-url origin NEW_URL、一度消してから追加したいならgit remote remove origin→git remote add ...の順で実行します。git pull --rebase origin mainで取り込んでから再push、または個人ブランチならgit push --force-with-leaseで解決します。詳細は“non-fast-forward”で拒否されたときの解決方法を参照。cdでリポジトリに入っていない、(2) 別ディレクトリで操作している、(3) .gitが消えた、のいずれかの可能性が高いです。pwdとgit remote -vで状態を確認しましょう。git remote set-url origin NEW_URLでURLを書き換えるだけです。HTTPS→SSHはgit@github.com:USER/REPO.git、SSH→HTTPSはhttps://github.com/USER/REPO.gitに変更します。.gitが原則です。サブプロジェクトを別リポジトリとして管理するならsubmoduleやgit subtree、あるいはpnpm workspace・yarn workspaces等のパッケージマネージャ機能と組み合わせます。originは自分のクローン元(通常はfork or 自リポジトリ)、upstreamはfork開発における本家を指す慣習的な名前です。詳しくはoriginとupstreamの違いと使い分けを参照。関連記事
- 【Git】「Permission denied (publickey)」エラーの原因と解決方法 — 認証系エラーの対処
- 【Git】pushしようとしたら”non-fast-forward”で拒否されたときの解決方法 — push拒否の別系統
- 【Git】「error: failed to push some refs to」エラーが発生した時の解決法 — push系エラーの総合対処
- 【Git】originとupstreamの違いと使い分け完全ガイド — リモート概念の深掘り
- 【Git】リモートブランチを確認する方法 — リモート状態の確認
- 【Git】ブランチ名を変更したらpushできなくなったときの対処法 — リネーム後のpush問題
- 【Git】pullで「untracked working tree files would be overwritten by merge」の解決方法 — pull系の別エラー
- 【Git】よく使うgitコマンドまとめ — 日常コマンドの早見表
まとめ
- 「does not appear to be a git repository」は「リモートがGitリポジトリとして認識できない」合図
- まず
git remote -v・pwd・git rev-parse --show-toplevelの3つで診断 - 原因は6パターン:①未登録/②typo/③URL誤り/④init忘れ/⑤ディレクトリミス/⑥.git破損
- 対処は
remote add/rename/set-url/git init/cd/再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する、命名規則(origin/upstream)を徹底する、といった習慣で予防できます。