GitHub

冒頭まとめ git remote add origin ...で次のエラーが出たら、同じ名前のリモートが既に登録されています。リモートは、取得先や送信先のリポジトリに付ける名前です。 error: remote origin already exists. まず登録済みの名前とURLを確認します。 git remote -v URLが目的のものなら追加し直す必要はありません。既存のoriginのURLを変えたいなら、addではなく次を使います。 git remote set-url origin https://github.com/OWNER/REPOSITORY.git URLは実際の接続先へ置き換えます。元の接続先も残したい場合は、後述する別名での追加を使ってください。 originは登録名であり接続エラーではない GitHubのリモート管理の公式説明は、このエラーを、ローカルリポジトリに存在する名前を再び追加しようとした状態と説明しています。 originは特別なURLやGitHub上のリポジトリ名ではなく、手元で接続先を識別する登録名です。別のURLを指定しても、同じ名前が使われていれば追加は拒否されます。 逆に、同じURLを違う名前で登録することもできます。エラーの判定対象はURLの一致ではなく、名前の重複です。 今回のGit 2.51.1による確認では、clone済みのリポジトリに再びoriginを追加すると、上記の文言と終了コード3になりました。失敗した追加操作の前後で、リポジトリの設定ファイルは変わっていませんでした。 URLの存在やアクセス権を確認する段階のエラーではありません。再試行やパスワード変更だけで、名前の重複がなくなるわけではありません。 登録済みのURLと作業場所を確認する 別のプロジェクトを操作していないかも含めて、現在の対象を確認します。 git rev-parse --show-toplevel git remote -v git remote get-url --all origin git remote get-url --push --all origin --show-toplevelは作業ディレクトリの最上位を表示します。get-urlの後半二つは、取得側と送信側のURLをそれぞれ確認する指定です。 通常の設定例では、git remote -vに次のように表示されます。 origin https://github.com/OWNER/REPOSITORY.git (fetch) origin https://github.com/OWNER/REPOSITORY.git (push) fetchは取得、pushは送信に使うURLです。二行あるだけで、originが二重登録されているという意味ではありません。 cloneの公式文書によると、cloneでは既定で複製元がoriginとして登録されます。clone後に、初期化済みのリポジトリ向けのremote add origin手順を繰り返せば、名前が重なります。clone --originなどで名前を指定した場合は、実際の一覧で判断します。 URLに認証情報が含まれている場合は、確認結果をそのまま公開しないでください。 URLの変更にはset-urlを使う 既存の接続先が誤っている、または同じリポジトリへのHTTPSとSSHを切り替えたい場合は、URLを変更します。 git remote set-url origin https://github.com/OWNER/REPOSITORY.git git remote -v Gitのremote公式文書には、既存リモートのURLを変更するset-urlが説明されています。今回の最小例でも、変更後のURLが表示され、現在のコミットとorigin/mainなどの追跡情報は残りました。 ...

冒頭まとめ git pullで次のエラーが出た場合、取得した履歴を現在のブランチへどう取り込むかが指定されていません。 fatal: Need to specify how to reconcile divergent branches. 典型的には、ローカルとリモートの両方に、それぞれ独自のコミットがあります。コミットは変更を記録した単位です。マージで両方の履歴を結合するか、リベースでローカルのコミットを取り込み先の上に作り直すかを決めます。 既存のコミットをそのまま残して結合するなら、今回の操作だけマージを指定できます。 git pull --no-rebase --ff origin main originとmainは例です。実際の接続先と取り込むブランチに置き換えてください。共同開発では、プロジェクトで決めている方法に合わせます。 エラーは取り込み方を決める段階で出る Git 2.51のpull公式文書は、ローカルがリモートより遅れているだけなら早送りし、履歴が分岐していればマージかリベースを指定する必要があると説明しています。早送りは、新しいコミットを作らず、ブランチの先端を既存のコミットへ進める更新です。 Git 2.51.1のpull実装では、早送りできず、現在の履歴が既に取り込み先を含んでいるわけでもない場合に、分岐と判定します。取り込み方が未指定なら、マージやリベースを始める前に終了します。 したがって、このエラーだけでファイルの競合が起きたとは判断できません。ただし、pullの前半にあるfetchは既に実行されています。現在のコミットが変わらなくても、origin/mainなどのリモート追跡情報は更新されている場合があります。 この記事ではGit 2.51.1を使い、共通のコミットからローカルとリモートを別々に進めて確認しました。方式未指定のpullは終了コード128となり、現在のコミットは変わらず、上記のエラーとhint:付きの案内が表示されました。 接続先・分岐・設定を確認する 取り込む対象と現在の状態を確認します。 git status git remote -v git branch -vv git fetch origin git log --oneline --graph --decorate --all git rev-list --left-right --count HEAD...origin/main 最後のコマンドは、二つの履歴のうち片側だけに存在するコミット数を表示します。HEAD側が左、origin/main側が右です。今回の再現では1 1となり、両側に独自のコミットがありました。接続先やブランチ名のエラーが出た場合は、先にその指定を直します。 次に、設定値と、その設定がどのファイルから来ているかを確認します。 git config --show-origin --get pull.rebase git config --show-origin --get pull.ff git branch --show-current 現在のブランチがmainなら、ブランチ専用の設定も確認します。 ...

冒頭まとめ git pullやgit mergeで次のエラーが出る場合、Gitは結合する二つの履歴に共通の祖先となるコミットを見つけられていません。コミットは、変更内容を記録した単位です。 fatal: refusing to merge unrelated histories 通信をやり直すだけでは解消しません。接続先と対象ブランチを確認し、独立した二つの履歴を本当に結合したい場合だけ、--allow-unrelated-historiesを指定します。 git fetch origin git merge --allow-unrelated-histories origin/main originとmainは例です。実際の接続先とブランチ名に置き換えてください。このオプションは履歴の結合を許可するだけで、ファイルの競合を自動で解消するものではありません。 エラーが出る条件とGitの版 Gitのmerge公式文書は、共通の祖先がない履歴の結合を既定で拒否すると説明しています。独立して始まったプロジェクトの履歴を結合するための例外が、--allow-unrelated-historiesです。 この拒否はGit 2.9のリリースノートに記録されています。それ以前の既定動作は、共通の祖先がない履歴の結合も許可するものでした。別に作られた履歴が意図せず既存プロジェクトへ混ざることを防ぐため、動作が変更されました。 git pullでも、取得した履歴をマージで取り込む場合にこの判定が働きます。pullには履歴を組み直すrebase方式もあり、今回のオプションはマージ方式で使うものです。 ファイルの内容が同じでも、別々に作った最初のコミットが同じ履歴になるとは限りません。判断対象はファイルの一致ではなく、コミット間の親子関係です。 接続先と共通の祖先を確認する 最初に、別のプロジェクトを接続先に指定していないかを確認します。 git status git remote -v git branch --show-current git fetch origin git log --oneline --graph --decorate --all git merge-base HEAD origin/main git fetchはリモートの履歴を取得します。この段階では作業中のブランチへマージしません。取得後のorigin/mainと、現在のコミットを表すHEADを比べます。 merge-baseの公式文書によると、このコマンドは二つのコミットの共通祖先を探します。この記事のGit 2.51.1による確認では、独立した履歴に対して標準出力は空、終了コードは1でした。 ただし、出力がないだけで判断しないでください。ブランチ名が誤っているなどのエラーが表示された場合は、先にその問題を直します。 履歴を途中までしか取得していない浅いリポジトリでは、祖先をたどる情報が不足する場合もあります。 git rev-parse --is-shallow-repository trueなら、接続先を確認したうえで履歴全体を取得し、再確認します。 git fetch --unshallow origin git merge-base HEAD origin/main 浅い履歴の取得方法はfetchの公式文書に説明されています。共通の祖先が見つからない理由を確認する前に、結合の許可へ進まないようにします。 別々の初期化で二つの履歴ができる GitHubでREADME付きのリポジトリを作り、手元でも別にgit initしてコミットすると、それぞれ独立した最初のコミットができます。そこへ接続先を追加しても、過去の履歴の親子関係は変わりません。 ...

冒頭まとめ この記事は設定ミスの記事ではありません。 2026年8月6日から7日にかけて発生した、GitHub 側のサービス障害の記録です。 permissions の見直し、workflow ファイルの書き換え、トークンの再発行、ランナーの再登録——これらを行っても状況は変わりません。原因は利用者側の設定にないためです。 対象期間は、公式の調査開始が日本時間の8月7日 0:22（UTC 8月6日 15:22）、影響の緩和が確認されたのが8月7日 9:05（UTC 0:05）です。本記事の執筆時点で公式の状態は「監視中」であり、正式な解決の宣言はまだ出ていません。最新の状況は公式のインシデントページ（Incident with Actions）で確認してください。 この障害の特徴は、単一のエラー文言では説明できないことです。停止した処理の段階によって、症状がまったく違う形で現れました。「Actions が動かない」という同じ体験でも、どの段階で止まったかによって、取るべき対応が変わります。 何が起きたか：処理段階ごとの症状 公式の更新をもとに、停止した段階ごとに整理します。 処理段階 確認された症状 Webhook の受付 push や pull request がワークフローを作成しない ジョブのキュー queued のまま長時間開始しない、時間切れになる ランナーの割り当て 既に無効になったジョブがランナーへ割り当てられる ジョブの実行 起動に失敗する、途中で失敗する Actions API REST API がエラーを返す、想定外の利用制限がかかる 関連サービス Pages、Copilot のレビューとエージェント、Enterprise Importer の遅延や失敗 とくに重要なのが1行目です。公式の説明によれば、復旧を助けるために webhook の起点が意図的に絞られていました。一時は全体の約15%しか処理されていない状態です。 つまり、push しても何も起きない、pull request を作ってもワークフローの一覧に何も現れない、という状況が発生していました。利用者から見れば「自分の設定が壊れた」ようにしか見えませんが、実際には復旧のための措置です。この段階で workflow ファイルを触っても、何も変わりません。 3行目も特徴的です。公式は途中で「既に有効でないジョブがランナーへ割り当てられている」問題を特定したと発表しています。GitHub 側が用意するランナーと、自前で用意するランナーの両方が影響を受けました。 利用者側の問題との見分け方 以下の兆候が複数当てはまる場合、原因は自分の設定ではありません。 ワークフローそのものが作成されない。特定のジョブが失敗するのではなく、実行が始まらないのが特徴です。 複数のリポジトリで同時に発生している。設定はリポジトリごとに独立しているため、同時発生は外部要因を示します。 GitHub 側のランナーと自前のランナーの両方で失敗している。この2つは実行環境が別なので、片方だけの設定問題では説明できません。 設定を変更していないワークフローまで失敗している。 Actions API や Pages など、Actions 以外にも同時に症状が出ている。 公式のステータスページにインシデントが掲載されている。 逆に、特定のジョブや特定の API 操作だけが再現性をもって失敗する場合は、利用者側の問題です。とくに Resource not accessible by integration のように権限を示す文言が特定の操作で必ず出るなら、そちらを調べてください（GitHub の Resource not accessible by integration の記事）。 ...

冒頭まとめ GitHub Actionsで次のエラーが出た場合、APIが壊れているのではなく、リクエストに使ったトークンがその操作を許可されていません。 RequestError [HttpError]: Resource not accessible by integration status: 403 同じリポジトリで、push や組織内部からの実行が起点なら、解決は失敗した操作に対応する permissions をワークフローへ追加することです。 たとえば、コードを読み、IssueとPull Requestへ書き込むジョブなら次のようにします。 permissions: contents: read issues: write pull-requests: write 必要な権限は操作ごとに違います。 リポジトリをcheckoutする → contents: read コミット、タグ、Releaseを書く → contents: write Issueへ書く → issues: write Pull Requestへ書く → pull-requests: write Check Runを作る → checks: write commit statusを書く → statuses: write コードスキャン結果を送る → security-events: write パッケージを公開する → packages: write OIDCトークンを発行する → id-token: write ただし、permissions を書けば必ず直るわけではありません。次の実行では、ワークフロー側から書き込み権限へ引き上げられないことがあります。 外部フォークからのpull_request Dependabotが作成したPull Request 呼び出し元が権限を与えていない再利用ワークフロー GITHUB_TOKENの対象外である別リポジトリや組織資源への操作 特に、外部フォークの失敗を直すために pull_request_target へ置き換え、Pull Request側のコードをcheckoutして実行するのは危険です。書き込み可能なトークンやシークレットを、信頼できないコードから利用できる状態にしないでください。 ...

冒頭まとめ git clone、git pull、git push で次のエラーが出た場合、GitHubとのSSH認証が完了していません。 git@github.com: Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. 最初に押さえるべきは、この時点では対象リポジトリの権限確認まで進んでいないことです。GitHub公式の説明でも、Permission denied はサーバーが接続を拒否した状態とされています。共同編集者の権限、ブランチ保護、リポジトリの公開・非公開を調べる前に、SSH認証を直します。 また、末尾の publickey は「公開鍵ファイルが壊れた」という意味ではありません。サーバーが続行を許可した認証方式が公開鍵認証だけで、その方式では利用者を確認できなかったという意味です。実際の認証では、端末にある秘密鍵で署名し、GitHubに登録した公開鍵で検証します。GitHubへ追加するのは .pub 側だけです。秘密鍵は送信も貼り付けもしません。 最初の診断は次の1行です。 ssh -vT git@github.com 注目するのは、長い出力の中に Offering public key があるかどうかです。 Offering public key がない → 使える鍵を見つけていない、または選択していない Offering public key はあるが、認証されない → 提示した鍵がGitHubの該当アカウントに登録されていない、または別の鍵を提示している Server accepts key の後に signing failed → 鍵は認識されたが、ssh-agentなどが署名できていない Hi USERNAME! You've successfully authenticated... → SSH認証は成功。次にリポジトリ権限、remote、SSOを確認する つまり、新しい鍵を作ることから始めないのが要点です。まず、失敗したGit操作と同じ端末・同じSSHクライアントが、どの鍵を提示したかを確定します。 ...

冒頭まとめ Host key verification failed. を出しているのは GitHub ではありません。**手元の SSH クライアント**です。意味は「接続先が名乗っている身元を、こちらでは確認できなかった」ということです。 認証の失敗ではない点に注意してください。鍵が正しいかを問う以前の段階で、相手が本物の github.com かどうかを確かめています。 実装を読むと、この段階には2つの分岐があります。1つは記録に無い場合です。相手の鍵を初めて見たとき、対話できる環境なら「この接続先の真正性を確認できません」と表示して確認を求めます。対話できない環境では、確認のしようがないので失敗します。自動処理やコンテナの中でこのエラーが出るのは、ほぼこの形です。 もう1つは記録と違う場合です。この場合は大きな警告が出ます。実装では「接続先の識別情報が変わった」という囲み枠に加えて、記録の何行目が該当するかまで表示されます。 そして重要なのは、この警告は「攻撃かもしれない」と「正当な鍵の交換かもしれない」の両方を意味することです。どちらかを判断するのは利用者の側です。判断材料はあります。GitHub は接続先の鍵の指紋を文書として公開し、API からも配信しています。突き合わせれば、自分で判断できます。 エラーの概要 記録に無い場合、対話できる環境ではこう表示されます。 The authenticity of host 'github.com (140.82.x.x)' can't be established. ED25519 key fingerprint is SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU. Are you sure you want to continue connecting (yes/no/[fingerprint])? 対話できない環境では確認が省略され、そのまま次の文言で終わります。 Host key verification failed. fatal: Could not read from remote repository. 記録と違う場合は、囲み枠付きの警告になります。 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ ... Add correct host key in /home/user/.ssh/known_hosts to get rid of this message. Offending RSA key in /home/user/.ssh/known_hosts:12 Host key verification failed. Offending の行に、記録ファイルの何行目が該当するかが書かれています。この番号があれば、消すべき行が特定できます。 ...