Git Runbook

症状 .gitignore にファイルやディレクトリを追加したのに、git status で変更が検出され続ける。 結論：まずこれを確認 そのファイルは すでに Git に追跡（track）されている 可能性が高い .gitignore は 新規ファイルにのみ有効 で、追跡済みファイルには効かない 追跡を解除するには git rm --cached でキャッシュを削除する 操作フロー flowchart TD A[.gitignoreが効かない] --> B{対象ファイルは<br>すでに追跡されている?} B -->|Yes| C[git rm --cached で<br>追跡を解除] B -->|No| D{.gitignoreの<br>パターンは正しい?} C --> E[変更をコミット] D -->|Yes| F{.gitignoreの<br>文字コード・改行は正常?} D -->|No| G[パターンを修正] F -->|Yes| H[git check-ignore で確認] F -->|No| I[UTF-8・LFで保存し直す] G --> A I --> A H --> J{無視対象として<br>認識されている?} J -->|Yes| C J -->|No| G よくある原因 すでに追跡済み: .gitignore に追加する前にコミットしたファイルは、追跡が継続される パターンの書き方が間違っている: / の有無、* の使い方で挙動が変わる ファイル名のタイポ: .gitignore 自体のファイル名や、中のパターンにタイポがある 文字コードの問題: BOM付きUTF-8やWindows改行（CRLF）で正しく認識されない グローバル gitignore との競合: ~/.gitignore_global の設定が影響している場合がある サブディレクトリの .gitignore: 親ディレクトリの設定が子で上書きされている 否定パターンの誤用: ! で除外を解除しているつもりが効いていない 操作手順 ステップ1: 対象ファイルが追跡されているか確認する git ls-files ファイル名 🔍 チェックポイント: ファイル名が表示されれば「追跡済み」。何も表示されなければ「未追跡」 ...

症状 Gitで管理しているファイルを誤って削除してしまい、復元したい。 結論：まずこれを確認 git status で削除がコミット済みか確認する コミット前なら git restore <ファイル名> で復元 コミット後なら git checkout <コミットハッシュ> -- <ファイル名> で復元 操作フロー flowchart TD A[ファイルが消えた] --> B{git statusを実行} B --> C{deleted: と表示される?} C -->|Yes| D[まだコミットしていない] C -->|No| E{ファイルが表示されない?} D --> F[git restore で復元] E -->|Yes| G[すでにコミット済み] G --> H[git log でコミットを探す] H --> I[git checkout で復元] F --> J[復元完了] I --> J よくある原因 rm コマンドで削除した - git rm ではなく通常の rm で削除した場合 git rm で削除した - ステージングされた状態で削除されている git clean を実行した - 追跡されていないファイルが削除された（復元不可の場合あり） ブランチを切り替えた - 別ブランチにはファイルが存在しない マージで削除された - コンフリクト解決時に削除された 過去のコミットで削除された - いつ削除されたか分からない状態 操作手順 ステップ1: 現在の状態を確認する まず git status で削除の状態を確認する。 ...

症状 「このコードは誰がいつ書いたのか」「特定の行の変更履歴を追いたい」ときに git blame の使い方がわからない 結論：まずこれを確認 git blame -L 行番号,行番号 ファイル名 これで特定行の最終変更者・コミットを確認できる。 操作フロー flowchart TD A[特定行の履歴を調べたい] --> B{調べたい範囲は?} B -->|1行だけ| C[git blame -L n,n ファイル] B -->|複数行| D[git blame -L n,m ファイル] C --> E{さらに前の履歴を見たい?} D --> E E -->|Yes| F[git blame コミットID^ -L n,n ファイル] E -->|No| G[完了] F --> H{まだ遡りたい?} H -->|Yes| F H -->|No| G よくある原因 行番号の指定方法がわからない — -L オプションを使う ファイル全体が表示されて見づらい — 行範囲を絞ると解決 変更前のコミットを見たい — コミットID^ で1つ前を指定 リネーム前のファイルを追えない — -C オプションで追跡可能 移動されたコードの元を知りたい — -C -C -C で検出範囲を拡大 空白変更が邪魔 — -w オプションで無視できる 出力が長すぎる — ページャーや行指定で絞る 操作手順 ステップ1: 対象ファイルの行番号を確認する エディタや cat -n で行番号を確認する。 ...

症状 git commit --amend でコミットを修正した後、git push が rejected される。 ! [rejected] main -> main (non-fast-forward) error: failed to push some refs to 'origin/main' 結論：まずこれを確認 --amend はコミットを「書き換える」ため、リモートと履歴が分岐する 解決には git push --force-with-lease を使う 他の人と共有しているブランチでは使用禁止 操作フロー flowchart TD A[amend後にpushがreject] --> B{ブランチは自分専用?} B -->|Yes| C[git push --force-with-lease] B -->|No| D[force pushは危険] D --> E[新しいコミットで修正を追加] C --> F{pushできた?} F -->|Yes| G[完了] F -->|No| H[リモートが更新されている] H --> I[git fetch して状況確認] よくある原因 履歴の分岐: --amend は新しいコミットを作成し、古いコミットを置き換えるため リモートに既にpush済み: amend前のコミットがリモートに存在する 他の人がpush済み: 自分がfetch後に他の人がpushしている ブランチ保護ルール: GitHubでforce pushが禁止されている 権限不足: リポジトリへのwrite権限がない 間違ったリモート指定: originが期待と異なるリポジトリを指している 操作手順 ステップ1: 現在の状態を確認する git status 🔍 チェックポイント: 「Your branch and ‘origin/xxx’ have diverged」と表示されれば、履歴が分岐している ...

症状 git checkout や git switch を実行したら「detached HEAD」と表示された。または git status で「HEAD detached at xxxxx」と表示されている。 結論：まずこれを確認 git status で現在の HEAD 位置を確認する 変更をコミット済みなら、ブランチを作成して救出する 変更がなければ、git switch ブランチ名 で元に戻る 操作フロー flowchart TD A[detached HEAD 状態] --> B{未コミットの変更あり?} B -->|Yes| C[git stash で退避] B -->|No| D{コミット済みの変更あり?} C --> D D -->|Yes| E[git branch 新ブランチ名 で救出] D -->|No| F[git switch ブランチ名 で戻る] E --> G[git switch 新ブランチ名] G --> H[必要なら既存ブランチにマージ] F --> I[解決] H --> I よくある原因 特定のコミットを checkout した - git checkout コミットハッシュ を実行した タグを checkout した - git checkout v1.0.0 のようにタグを指定した リモートブランチを直接 checkout した - git checkout origin/main を実行した rebase 中に中断した - rebase 操作が途中で止まっている サブモジュールの更新 - サブモジュール内で特定コミットに切り替わった bisect 実行中 - git bisect でバグ調査中の状態 操作手順 ステップ1: 現在の状態を確認する git status 🔍 チェックポイント: 「HEAD detached at」または「HEAD detached from」と表示される ...

症状 git fetchとgit pullの違いがわからず、どちらを使えばいいか迷っている 結論：まずこれを確認 git fetch = リモートの情報を取得するだけ（ローカルのファイルは変わらない） git pull = git fetch + git merge（ローカルのファイルが変更される） 迷ったらgit fetchを使う（安全） 操作フロー flowchart TD A[リモートの変更を確認したい] --> B{ローカルに未コミットの変更がある?} B -->|Yes| C[git stash で退避] B -->|No| D{すぐにマージしたい?} C --> D D -->|Yes| E[git pull] D -->|No| F[git fetch] F --> G[git log origin/main で差分確認] G --> H{マージする?} H -->|Yes| I[git merge origin/main] H -->|No| J[作業継続] E --> K[完了] I --> K よくある原因 fetchとpullの違いを知らずにpullを使い、意図しないマージが発生した fetchだけしてマージを忘れ、ローカルが古いままになっていた pullしたらコンフリクトが発生してパニックになった リモートの変更を確認せずにpullして、作業中のコードが上書きされた fetch後にorigin/mainとmainの違いを理解していなかった 操作手順 ステップ1: 現在の状態を確認する git status 🔍 チェックポイント: 未コミットの変更がある場合は、先にgit stashで退避するか、コミットしておく ...

症状 git merge 実行後にコンフリクトが発生し、解消作業を中止してマージ前の状態に戻したい 結論：まずこれを確認 git status で現在の状態を確認する マージ中なら git merge --abort で中止できる 作業中の変更がある場合は先に退避（stash）を検討する 操作フロー flowchart TD A[コンフリクト発生] --> B{git status で状態確認} B --> C{Unmerged paths あり?} C -->|Yes| D{作業中の変更を残す?} C -->|No| E[マージは完了済み] D -->|残さない| F[git merge --abort] D -->|残したい| G[git stash で退避してから abort] F --> H[マージ前の状態に戻る] G --> H E --> I[git reset で戻すか検討] よくある原因 コンフリクトの量が多すぎて手に負えない - 一度中止して戦略を練り直す 間違ったブランチをマージしてしまった - abort して正しいブランチを選び直す コンフリクト解消中に別の変更をしてしまった - 状態が複雑になり最初からやり直したい マージの方向を間違えた - feature を main にマージすべきところを逆にした リモートの最新を取り込んでからマージしたい - 一度中止して pull してからやり直す 操作手順 ステップ1: 現在の状態を確認する git status 🔍 チェックポイント: 以下のような表示があればマージ中 ...

症状 git push 実行時に以下のようなエラーが表示される。 ! [rejected] main -> main (non-fast-forward) error: failed to push some refs to 'origin' hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. 結論：まずこれを確認 リモートに自分以外のコミットがないか git fetch && git log origin/main..HEAD で確認 ある場合は git pull --rebase でリモートの変更を取り込む ない場合は意図せず履歴が書き換わっていないか確認 操作フロー flowchart TD A[git push が rejected] --> B{git fetch して確認} B --> C{リモートに新しいコミットあり?} C -->|Yes| D[git pull --rebase を実行] C -->|No| E{ローカルで履歴を書き換えた?} D --> F[コンフリクトあり?] F -->|Yes| G[コンフリクト解消] F -->|No| H[git push を再実行] G --> H E -->|Yes| I[履歴の整合性を確認] E -->|No| J[ブランチ名の確認] I --> K[force push が必要か判断] J --> L[正しいリモートか確認] よくある原因 リモートに他の人がpushした — チーム開発で最も多い原因 別端末で先にpushした — 同じ作業を複数環境で行っている場合 git commit –amend を使った — 既にpush済みのコミットを修正した git rebase を使った — push済みのブランチをリベースした git reset を使った — push済みの履歴を巻き戻した ブランチ名が違う — ローカルとリモートで異なるブランチを指定している フォークしたリポジトリを操作している — upstreamとoriginを混同している 操作手順 ステップ1: 現在の状態を確認する git status git log --oneline -5 🔍 チェックポイント: 自分がどのブランチにいるか、最新のコミットが何かを確認 ...

症状 git revert でマージコミットを取り消そうとしたら「error: commit is a merge but no -m option was given」と表示される 結論：まずこれを確認 マージコミットの revert には -m オプション（親番号の指定）が必要 通常は -m 1 を指定する（マージ先のブランチを残す） git log --oneline でマージコミットのハッシュを確認してから実行する 操作フロー flowchart TD A[マージを取り消したい] --> B{push済み?} B -->|Yes| C[git revert を使う] B -->|No| D[git reset も選択肢] C --> E{マージコミット?} E -->|Yes| F[git revert -m 1 を使う] E -->|No| G[git revert のみでOK] F --> H[親番号を確認] H --> I[git log で親を確認] I --> J[git revert -m 1 ハッシュ] J --> K[git status で確認] G --> K D --> L[git reset --hard] よくある原因 -m オプションを付けていない → マージコミットには親が2つあるため、どちらの親に戻すか指定が必要 親番号を間違えている → -m 1 はマージ先（通常main）、-m 2 はマージ元（feature）を指す マージコミットかどうか確認していない → git log で親が2つあるか確認する revert後に再マージできない → revertのrevertが必要になる場合がある コンフリクトが発生した → revert時も通常のコンフリクト解決と同様に対処する 間違ったコミットをrevertした → revertしたコミット自体をrevertする 操作手順 ステップ1: マージコミットを特定する git log --oneline --graph -10 出力例： ...

症状 作成したGitタグを削除したいが、ローカルとリモートの両方から消す方法がわからない 結論：まずこれを確認 ローカル削除: git tag -d タグ名 リモート削除: git push origin --delete タグ名 削除前に git tag -l で対象タグを確認する 操作フロー flowchart TD A[タグを削除したい] --> B{削除対象を確認} B --> C[git tag -l でタグ一覧表示] C --> D{ローカルのみ削除?} D -->|Yes| E[git tag -d タグ名] D -->|No| F{リモートも削除?} F -->|Yes| G[git tag -d タグ名] G --> H[git push origin --delete タグ名] E --> I[削除完了を確認] H --> I I --> J[git tag -l で確認] よくある原因 タグ名を間違えて作成した - タイポや命名規則のミス リリースを取り消すことになった - タグを付けたコミットが不適切だった 古いタグを整理したい - 不要になったタグの掃除 同じタグ名を別のコミットに付け直したい - 一度削除してから再作成が必要 CI/CDパイプラインで誤ってタグが作成された - 自動化による意図しないタグ テスト用のタグを消し忘れていた - 開発中に作った一時的なタグ 操作手順 ステップ1: 削除対象のタグを確認する # 全タグを一覧表示 git tag -l # 特定のパターンに一致するタグを表示（例: v1.* で始まるタグ） git tag -l "v1.*" # タグの詳細情報を確認 git show タグ名 🔍 チェックポイント: 削除したいタグ名が正しく表示されていることを確認 ...

症状 GitリポジトリのリモートURL（origin）を変更したい。HTTPSからSSHに変えたい、リポジトリを移行した、組織が変わったなど。 結論：まずこれを確認 git remote -v で現在のリモートURLを確認する git remote set-url origin 新しいURL で変更する git remote -v で変更後のURLを確認する 操作フロー flowchart TD A[リモートURLを変更したい] --> B[git remote -v で現在のURL確認] B --> C{変更理由は?} C -->|HTTPS→SSH| D[SSHのURLを取得] C -->|SSH→HTTPS| E[HTTPSのURLを取得] C -->|リポジトリ移行| F[新しいリポジトリのURLを取得] C -->|組織/ユーザー名変更| G[新しいURLを取得] D --> H[git remote set-url origin 新URL] E --> H F --> H G --> H H --> I[git remote -v で確認] I --> J{正しく変更された?} J -->|Yes| K[git fetch で接続テスト] J -->|No| L[URLを再確認して再実行] K --> M{接続成功?} M -->|Yes| N[完了] M -->|No| O[認証設定を確認] よくある原因 HTTPSからSSHへ変更したい - パスワード入力を省略したい、2FA導入後の対応 SSHからHTTPSへ変更したい - SSHキー設定の問題を回避したい リポジトリを別の場所に移行した - 組織間移動、GitHubからGitLabへ移行など ユーザー名や組織名が変わった - URLに含まれる名前が変更された フォーク元からfork先に変更したい - upstream を origin に変更 ミラーリポジトリへ変更 - 別サーバーのリポジトリを指定したい タイプミスの修正 - 最初の設定時にURLを間違えた 操作手順 ステップ1: 現在のリモートURLを確認する git remote -v 🔍 チェックポイント: origin の fetch と push のURLが表示される ...

症状 「以前は動いていた機能がいつの間にか壊れている。どのコミットでバグが入ったかわからない」 結論：まずこれを確認 git bisect start で二分探索を開始する 正常なコミットを git bisect good、バグのあるコミットを git bisect bad で指定する Git が自動でコミットを絞り込み、原因コミットを特定する 操作フロー flowchart TD A[バグを発見] --> B[正常だったコミットを特定] B --> C[git bisect start] C --> D[git bisect bad で現在のコミットをマーク] D --> E[git bisect good で正常コミットをマーク] E --> F{Gitが中間コミットをチェックアウト} F --> G[動作確認] G --> H{バグあり?} H -->|Yes| I[git bisect bad] H -->|No| J[git bisect good] I --> F J --> F F --> K[原因コミットを特定] K --> L[git bisect reset で終了] よくある原因 コミット数が多すぎて手動確認が困難 - 数十〜数百コミットの中から原因を探す必要がある いつからバグがあるか不明 - 明確な「正常だった時点」を思い出せない 複数人での開発で変更が追えない - 他のメンバーの変更が原因の可能性がある テストがなく自動検出できない - 手動確認に頼るしかない リリース後に発覚したバグ - 本番環境で初めて気づいた問題 マージコミットが多い - 履歴が複雑で追跡が難しい 操作手順 ステップ1: 現在の状態を確認する git status git log --oneline -20 🔍 チェックポイント: 作業中の変更がないこと。未コミットの変更があると bisect 中に失われる可能性がある ...

症状 別ブランチの複数コミットを現在のブランチに取り込みたい 結論：まずこれを確認 git log --oneline <ブランチ名> で取り込みたいコミットのハッシュを特定する 範囲指定なら git cherry-pick <開始>^..<終了> を使う 個別指定なら git cherry-pick <hash1> <hash2> <hash3> を使う 操作フロー flowchart TD A[複数コミットを取り込みたい] --> B{コミットは連続している?} B -->|Yes| C[範囲指定で cherry-pick] B -->|No| D[個別にハッシュを指定] C --> E[git cherry-pick 開始^..終了] D --> F[git cherry-pick hash1 hash2 hash3] E --> G{コンフリクト発生?} F --> G G -->|Yes| H[コンフリクト解消] G -->|No| I[完了] H --> J[git add → git cherry-pick --continue] J --> G よくある原因 cherry-pick がうまくいかない・迷う原因として以下がある。 ...

症状 git rebase を実行中に「CONFLICT」と表示され、リベースが途中で止まる 結論：まずこれを確認 git status でコンフリクトしているファイルを確認 ファイルを編集してコンフリクトマーカーを解消 git add → git rebase --continue で再開 操作フロー flowchart TD A[rebase中にCONFLICT発生] --> B{git statusで状態確認} B --> C[コンフリクトファイルを特定] C --> D{解決方法を選択} D -->|解決して続行| E[ファイルを編集] D -->|rebaseを中止| F[git rebase --abort] E --> G[コンフリクトマーカーを削除] G --> H[git add ファイル名] H --> I[git rebase --continue] I --> J{まだコンフリクトある?} J -->|Yes| C J -->|No| K[rebase完了] F --> L[rebase前の状態に戻る] よくある原因 同じ行を別々のコミットで編集した - 最も一般的な原因 ファイルの削除と編集が競合した - 片方で削除、片方で編集した場合 ブランチの分岐後に base ブランチが大きく変更された - 長期間マージしていない場合に発生しやすい リネームと編集が競合した - ファイル名変更と内容変更が同時に起きた場合 バイナリファイルの変更が競合した - 画像やPDFなどの自動マージ不可ファイル 空白や改行コードの差異 - OS間の改行コード違いで発生することがある 操作手順 ステップ1: 現在の状態を確認する git status 🔍 チェックポイント: both modified: や Unmerged paths: にファイル名が表示される ...

症状 git reset でコミットを取り消したいが、--soft と --hard のどちらを使うべきかわからない 結論：まずこれを確認 変更を残してコミットだけ取り消す → git reset --soft 変更も含めて完全に元に戻す → git reset --hard（⚠️ データ消失の可能性あり） 迷ったら --soft を使う（安全） 操作フロー flowchart TD A[コミットを取り消したい] --> B{変更内容を残す?} B -->|残す| C[git reset --soft] B -->|消す| D{本当に消していい?} D -->|はい| E[git reset --hard] D -->|いいえ| C C --> F[変更がステージング状態に戻る] E --> G[⚠️ 変更が完全に消える] F --> H[git status で確認] G --> H よくある原因 コミットメッセージを間違えた → --soft で取り消して再コミット コミットに含めるファイルを間違えた → --soft で取り消してやり直し 作業を完全にやり直したい → --hard で指定位置まで戻す 複数のコミットを1つにまとめたい → --soft で取り消してまとめてコミット 間違ったブランチにコミットした → --soft で取り消し、正しいブランチで再コミット 実験的な変更を完全に破棄したい → --hard で戻す 操作手順 ステップ1: 現在の状態を確認する git status git log --oneline -5 🔍 チェックポイント: 取り消したいコミットのハッシュ値を確認する ...

症状 git push や git pull 実行時に「Permission denied (publickey)」と表示され、リモートリポジトリに接続できない。 結論：まずこれを確認 SSH鍵が存在するか確認：ls -la ~/.ssh/ GitHubに鍵が登録されているか確認：ssh -T git@github.com 正しい鍵が使われているか確認：ssh-add -l 操作フロー flowchart TD A[Permission denied発生] --> B{SSH鍵は存在する?} B -->|No| C[SSH鍵を生成する] B -->|Yes| D{ssh-agentに登録済み?} D -->|No| E[ssh-addで鍵を登録] D -->|Yes| F{GitHubに公開鍵登録済み?} F -->|No| G[GitHubに公開鍵を登録] F -->|Yes| H{リモートURLはSSH形式?} H -->|No| I[URLをSSH形式に変更] H -->|Yes| J[~/.ssh/configを確認] C --> D E --> F G --> K[接続テスト] I --> K J --> K K --> L{成功?} L -->|Yes| M[完了] L -->|No| N[鍵のパーミッション確認] よくある原因 SSH鍵が存在しない - 鍵を一度も生成していない、または別のPCで作成した鍵を移行していない ssh-agentに鍵が登録されていない - 鍵ファイルはあるが、認証エージェントに読み込まれていない GitHubに公開鍵が登録されていない - ローカルの鍵とGitHub側の登録が紐づいていない リモートURLがHTTPS形式になっている - SSH認証ではなくHTTPS認証が使われている 鍵ファイルのパーミッションが不正 - 秘密鍵が他ユーザーから読める状態になっている ~/.ssh/configの設定ミス - 複数鍵を使い分ける設定に誤りがある GitHubアカウントが異なる - 別アカウントの鍵が優先されている 操作手順 ステップ1: SSH鍵の存在を確認する ls -la ~/.ssh/ 🔍 チェックポイント: id_ed25519 と id_ed25519.pub（または id_rsa と id_rsa.pub）が表示されれば鍵は存在する ...

症状 git stash pop を実行したらコンフリクトが発生し、stash が消えずに残っている。 結論：まずこれを確認 git status でコンフリクトしているファイルを確認する コンフリクトを手動で解消してから git add する stash は自動で消えないので、解消後に git stash drop で手動削除する 操作フロー flowchart TD A[git stash pop でコンフリクト発生] --> B{git status で状態確認} B --> C[コンフリクトファイルを特定] C --> D{コンフリクトを解消できる?} D -->|Yes| E[ファイルを編集してコンフリクト解消] D -->|No| F[git checkout --theirs or --ours で選択] E --> G[git add でステージング] F --> G G --> H[git stash drop で stash 削除] H --> I[解決完了] D -->|中断したい| J[git checkout -- ファイル名] J --> K[stash は残ったまま] よくある原因 同じファイルを編集していた - stash 保存時と現在のブランチで同一ファイルに変更がある ブランチを切り替えた後に pop した - 想定と異なるブランチで pop を実行した 他のメンバーの変更が取り込まれた - pull 後に stash pop したため差分が生じた stash が古い - 長期間放置した stash を適用しようとした 複数の stash を混同した - 意図しない stash を pop した ファイル名やパスが変更された - リネーム後のファイルに適用しようとした 操作手順 ステップ1: 現在の状態を確認する git status 🔍 チェックポイント: both modified: と表示されているファイルがコンフリクト対象 ...

症状 git submodule update を実行してもエラーが出る、または submodule の内容が更新されない。 結論：まずこれを確認 git submodule status で submodule の状態を確認する 初期化されていなければ git submodule init を先に実行する --remote オプションの有無で挙動が変わることを理解する 操作フロー flowchart TD A[submodule update でエラー/更新されない] --> B{git submodule status を確認} B -->|先頭に - がある| C[初期化されていない] B -->|先頭に + がある| D[ローカルに未コミットの変更あり] B -->|先頭にスペース| E[正常な状態] C --> F[git submodule init を実行] F --> G[git submodule update を再実行] D --> H[submodule内の変更を確認] H --> I{変更を残す?} I -->|Yes| J[submodule内でcommit/stash] I -->|No| K[git submodule update --force] E --> L{最新を取得したい?} L -->|Yes| M[git submodule update --remote] L -->|No| N[親リポジトリ記録のコミットを確認] よくある原因 submodule が初期化されていない - clone 直後は init が必要 submodule 内にローカル変更がある - 未コミットの変更があると update が止まる .gitmodules と .git/config の不整合 - URL やパスが一致していない SSH 鍵や認証の問題 - submodule のリモートにアクセスできない submodule のパスが変更された - 親リポジトリで移動・削除された ネットワークの問題 - リモートに接続できない サブモジュールが detached HEAD 状態 - ブランチ追跡が設定されていない 操作手順 ステップ1: submodule の状態を確認する git submodule status 出力の見方： ...

症状 GitHubでプルリクエスト（PR）を作成またはマージしようとすると「This branch has conflicts that must be resolved」と表示される。 結論：まずこれを確認 ローカルで最新の main（またはベースブランチ）を取得する 作業ブランチにマージまたはリベースしてコンフリクトを解消する 解消後にプッシュしてPRを更新する 操作フロー flowchart TD A[PRでコンフリクト発生] --> B{ローカルで解消?<br>GitHub上で解消?} B -->|ローカル| C[最新のbaseブランチを取得] B -->|GitHub上| D[Resolve conflicts ボタン] C --> E{merge? rebase?} E -->|merge| F[git merge main] E -->|rebase| G[git rebase main] F --> H[コンフリクト箇所を編集] G --> H D --> H H --> I[git add でステージング] I --> J{merge? rebase?} J -->|merge| K[git commit] J -->|rebase| L[git rebase --continue] K --> M[git push] L --> N[git push --force-with-lease] M --> O[PR更新完了] N --> O よくある原因 ベースブランチが更新された - PR作成後に main に新しいコミットが追加された 同じファイルを複数人が編集 - 同じ行を別々のブランチで変更した ファイルの削除と編集が競合 - 一方が削除、一方が編集した ブランチが古すぎる - 長期間マージされずにベースブランチと乖離した 自動マージツールの限界 - 近接した行の変更は自動解決できない リネームと編集の競合 - ファイル名変更と内容変更が同時に起きた 操作手順 ステップ1: 現在の状態を確認する git status git branch -a 🔍 チェックポイント: 作業ブランチにいることを確認する。未コミットの変更がある場合は先にコミットまたはスタッシュする。 ...

症状 GitHubやGitLabのリモートブランチを削除したいが、方法がわからない・削除できない 結論：まずこれを確認 git branch -r でリモートブランチ一覧を確認する git push origin --delete ブランチ名 で削除する 削除権限があるか確認する（protectedブランチは削除不可） 操作フロー flowchart TD A[リモートブランチを削除したい] --> B{削除対象のブランチ名を確認した?} B -->|No| C[git branch -r で一覧確認] B -->|Yes| D{protectedブランチ?} C --> D D -->|Yes| E[GitHub/GitLab設定で解除が必要] D -->|No| F[git push origin --delete ブランチ名] F --> G{エラー発生?} G -->|No| H[削除完了] G -->|Yes| I{エラー内容を確認} I -->|permission denied| J[権限を確認] I -->|remote ref does not exist| K[ブランチ名を再確認] I -->|その他| L[解決しない場合へ] よくある原因 ブランチ名のタイプミス - リモートブランチ名を正確に指定していない protectedブランチに指定されている - GitHub/GitLab側の設定で削除が禁止されている 権限不足 - リポジトリへの書き込み権限がない すでに削除済み - ローカルの参照が古く、リモートには存在しない デフォルトブランチを削除しようとしている - main/masterは別のブランチに変更後でないと削除できない ネットワークエラー - リモートへの接続に失敗している 操作手順 ステップ1: リモートブランチの一覧を確認する git branch -r 🔍 チェックポイント: origin/ブランチ名 の形式で削除対象が表示されていることを確認する ...