うまくいかないとき集

よくある詰まりを 症状 → 原因 → 対処 で集めたハブです。認証（SSH / HTTPS）、改行（CRLF / LF）、permission denied、detached HEAD、コミット作者メール、push rejected、add 忘れなどを扱います。

参考（Git / GitHub 公式）

• git-config
• Connecting to GitHub with SSH
• gitattributes（改行コードの制御）
• Git config core.autocrlf
• git-checkout（detached HEAD）
• Managing multiple accounts' commit settings

目次

1. 認証エラー（HTTPS / PAT）
2. 認証エラー（SSH）
3. CRLF / LF（改行コード）の警告と衝突
4. Permission denied（ファイル・鍵の権限）
5. detached HEAD になった
6. コミットのメールアドレスが意図と違う
7. push が rejected される
8. add を忘れて commit してしまった
9. 症状別クイックリファレンス

認証エラー（HTTPS / PAT）

症状

remote: Support for password authentication was removed on August 13, 2021.fatal: Authentication failed for 'https://github.com/<user>/<repo>.git/'

原因

対処

1. GitHub の Settings > Developer settings > Personal access tokens で新しい PAT を発行する
2. 次回の push/pull 時にユーザー名と、パスワード欄には PAT の文字列を入力する
3. Windows の資格情報キャッシュを一度クリアしたい場合は、資格情報マネージャーから git:https://github.com のエントリを削除して再認証する

# 資格情報マネージャーを開く（Windows）control /name Microsoft.CredentialManager

一度正しく認証できると、キャッシュされて毎回聞かれなくなります。

認証エラー（SSH）

症状

git@github.com: Permission denied (publickey).fatal: Could not read from remote repository.

原因

対処

まず疎通確認をします。

ssh -T git@github.com

Hi <username>! You've successfully authenticated, but GitHub does not provide shell access.

このメッセージが出れば SSH 認証自体は成功しています。Permission denied のままなら、鍵の作成・登録状況を確認します。

# 公開鍵の一覧を確認（存在するか）ls ~/.ssh/*.pub# 鍵が無ければ新規作成ssh-keygen -t ed25519 -C "your_email@example.com"# agent に登録ssh-add ~/.ssh/id_ed25519

公開鍵（.pub の内容）を GitHub の Settings > SSH and GPG keys に登録します。登録するのは公開鍵（.pub）だけで、秘密鍵は絶対に共有しません。

CRLF / LF（改行コード）の警告と衝突

症状

warning: LF will be replaced by CRLF in script.sh.The file will have its original line endings in your working directory

シェルスクリプトを Linux 環境で実行すると bash: ./script.sh: /bin/bash^M: bad interpreter: No such file or directory のようなエラーになる、または diff を見ると ファイル全体が変更されたように見える こともあります。

原因

Windows は既定で改行を CRLF（\r\n）、Linux/macOS は LF（\n） を使います。Git の core.autocrlf 設定次第で、チェックアウト・コミット時に改行が自動変換されるため、意図しない変換が差分に紛れ込むことがあります。

対処

現在の設定を確認します。

git config --get core.autocrlf

Windows 環境であれば、通常は次で問題ありません。

git config --global core.autocrlf true

プロジェクト単位で改行を固定したい場合（チームで OS が混在する場合など）は、.gitattributes を使うほうが確実です。

# .gitattributes の例* text=auto*.sh text eol=lf*.bat text eol=crlf

設定を変えた後、既にリポジトリに入っているファイルに反映させるには再チェックアウトが必要です。

git add --renormalize .git status

Permission denied（ファイル・鍵の権限）

症状

error: unable to unlink 'file.txt': Permission denied

Bad permissions. Try removing permissions for user: Windows...Load key "/home/user/.ssh/id_ed25519": bad permissions

原因

対処

作業ファイルの場合は、該当ファイルを開いているアプリを閉じてから再実行します。

# 該当プロセスを確認する（Windows, 例）Get-Process | Where-Object { $_.MainWindowTitle -like "*file.txt*" }

SSH 鍵の権限エラーは、鍵ファイルのパーミッションを絞ることで解消します（WSL / Git Bash などの Unix 系シェル）。

chmod 600 ~/.ssh/id_ed25519

Windows ネイティブ環境（PowerShell）で同様の警告が出る場合は、OpenSSH の権限まわりの設定か、鍵ファイルをユーザー専用フォルダに置き直すことで解消することが多いです。

detached HEAD になった

症状

Note: switching to 'a1b2c3d'.You are in 'detached HEAD' state. You can look around, make experimentalchanges and commit them, and you can discard any commits you make in thisstate without impacting any branches by switching back to a branch.

原因

git checkout <コミットハッシュ> や git checkout <タグ名> のように、ブランチ名ではなくコミットやタグを直接指定 してチェックアウトすると、HEAD がどのブランチにも属さない状態になります。

git switch は安全のため、この動作を既定では許可しません。git switch <コミットハッシュ> だけだと fatal: a branch is expected, got commit '...' で止まります。detached HEAD にするには git switch --detach <コミットハッシュ> のように --detach を明示します。

通常:        HEAD -> main -> コミットCdetached:    HEAD -> コミットC（mainなどのブランチ名を経由しない）

この状態でコミットしても、あとでブランチに切り替えると、そのコミットへの参照が失われることがあります（一定期間は reflog から復元可能ですが、初心者には分かりにくい落とし穴です）。

対処

まず、今何も変更していない・変更を保存したくない場合は、単純にブランチに戻ります。

git switch main

detached HEAD の状態で すでにコミットしてしまった 場合は、そのコミットを保持したいなら新しいブランチ名を付けて救出します。

git switch -c rescue-branch

これで、そのコミットは rescue-branch という名前のブランチに乗った状態になり、以降 main などに切り替えても失われません。

コミットのメールアドレスが意図と違う

症状

GitHub の Contributions（草）が反映されない、または commit の author が想定と違う名前・メールで記録されている。

git log -1 --format="%an <%ae>"

古い名前 <old-email@example.com>

原因

git config の user.name / user.email は、リポジトリごとのローカル設定が無ければグローバル設定が使われます。複数のメールアドレス（会社用・個人用など）を使い分けている場合、意図しない設定のままコミットしてしまうことがあります。

対処

現在の設定（グローバル・ローカルの両方）を確認します。

git config --global user.emailgit config --local user.email

このリポジトリだけ変更したい場合は --local（--global を付けない）で設定します。

git config user.name "正しい名前"git config user.email "correct-email@example.com"

すでに間違えてコミットしてしまった直前の 1 件だけを直す場合は、amend で author 情報を更新できます。

git commit --amend --author="正しい名前 <correct-email@example.com>" --no-edit

まだ push していない場合に限り安全です。push 済みの履歴を書き換えると、共有ブランチでは他の人に影響するため注意してください。GitHub 上でどのメールアドレスが自分のアカウントに紐づいているかは、GitHub の Settings > Emails でも確認できます。

push が rejected される

症状

! [rejected]        main -> main (fetch first)error: failed to push some refs to 'https://github.com/<user>/<repo>.git'hint: Updates were rejected because the tip of your current branch is behindhint: its remote counterpart.

原因

リモート側に、自分のローカルにはまだ無いコミットが存在する状態（non-fast-forward）です。他の PC や共同作業者が先に push した場合に典型的に起きます。

対処

git fetch origingit log --oneline main..origin/maingit pull# コンフリクトがあれば解消して commitgit push

この段階で force push（--force）は使わないでください。 履歴を上書きし、リモート側にしかないコミットを消してしまう可能性があります。まずは fetch して差分を把握し、pull で取り込んでから push し直す、という順序を徹底します。

add を忘れて commit してしまった

症状

git commit -m "機能を追加"

On branch mainnothing added to commit but untracked files present

または、意図したファイルの一部だけがコミットに含まれていない。

原因

git commit は ステージ済み（git add した）内容だけ をコミットします。ファイルを保存しただけでは、Git は変更を追跡していません。

編集した   → git add で気づく → git commit で記録される編集した   → git add を忘れる → git commit しても記録されない

対処

まず現在の状態を確認します。

git status

Changes not staged for commit:	modified:   src/app.jsUntracked files:	new-file.txt

必要なファイルを add してから、改めて commit します。

git add src/app.js new-file.txtgit commit -m "機能を追加"

直前のコミットに、忘れていたファイルだけ追加したい場合（まだ push していない場合に限る）は、amend で追記できます。

git add forgotten-file.txtgit commit --amend --no-edit

add 忘れを繰り返しがちな場合は、git commit の前に必ず git status を確認する、あるいは git add -A（追跡外ファイルも含めて全部ステージ）を使う運用に統一すると防ぎやすくなります。

git add -Agit statusgit commit -m "変更内容"

症状別クイックリファレンス

Git のトラブルは大きく分けると「認証」「改行・権限などの環境差」「HEAD やブランチの位置の誤解」「ステージし忘れ」「リモートとの同期不足」の 5 系統に整理できます。エラーメッセージ中の固有名詞（publickey、autocrlf、detached、rejected、untracked など）に着目すると、どの系統の問題かの見当が早くつきます。