このページで整理すること
- 対象repoを明記する
- 触るrepoと触らないrepo
- 共通ファイル名の混同防止
- 横断作業の停止条件
- 認証情報と秘密情報の確認
Codexでできること
Codexは、GitHub作業で確認したい観点を整理したり、PRやdiffを見る時のチェックリストを作ったり、release noteを読む時の確認項目を並べたりする補助に使えます。どのrepoを対象にするか、どのファイルを触るか、どのファイルを触らないかを文章にしてから渡すと、作業範囲が明確になります。
Codexだけに任せないこと
CodexがGitHubを何でも自動操作できるとは考えません。PRのマージ、releaseの採用、private/publicの判断、Secretsや.envの扱い、公式情報の確認は人間が行います。特に認証情報やトークンを貼り付けて相談する使い方は避けてください。
GitHubで確認すること
GitHubでは、repository、branch、diff、PR、release、private/public、Secretsの扱いを分けて見ます。Codexの報告だけで終わらせず、GitHub上の差分と公開範囲を確認してから次の作業に進みます。
複数リポジトリで実際に起きる取り違え
リポジトリを複数扱う時のトラブルは、技術的な難しさではなく「今どれを触っているか分からなくなる」ことから起きます。実際に起きやすい形を挙げます。
| 取り違え | 起きる状況 | 気づくタイミング |
|---|---|---|
| 別リポジトリに変更を入れる | 似た構成のサイトを並行して運用している | 公開URLを見て「変わっていない」と気づく |
| ブランチを間違える | 前の作業のブランチに残ったまま次を始めた | PRを作る段階、または後日 |
| 共通ファイルを片方だけ直す | 同じ仕組みを複数サイトへ横展開している | 数週間後、片方だけ古い挙動をする |
| 設定を別リポジトリのものと混同 | 公開先のパスやドメインが似ている | 反映先が違うことに後から気づく |
共通しているのは、間違えた瞬間には気づけず、公開URLを見て初めて分かる点です。だからこそ、作業のたびに「対象はどのリポジトリか」を指示文に書き、反映後は必ず公開URLで確認する手順が効きます。
取り違えを防ぐ具体策
複数リポジトリを扱うなら、次の3つを習慣にすると事故がほぼ無くなります。
- 作業前に現在地を確認する：どのリポジトリの、どのブランチにいるかを毎回確認してから始めます。前の作業の続きだと思い込むのが最も危険です。
- 指示文にリポジトリ名を明記する：「このファイルを直して」ではなく「〇〇リポジトリの△△を直して」と書きます。対象が言葉になっていれば、間違いに気づけます。
- 1つ終わってから次へ移る：複数のリポジトリを行き来しながら並行作業すると、頭の中の対象が入れ替わります。1つを完了・確認まで済ませてから次へ移ります。
また、同じ変更を複数リポジトリへ適用する場合は、一斉ではなく1つずつ進めてください。1つ目で問題が出れば、残りへ展開する前に気づけます。一斉に流すと、同じ問題が全リポジトリに広がります。
秘密情報・公開範囲の注意
private repositoryでも秘密情報を入れてよいわけではありません。APIキー、トークン、SSHキー、.env、顧客情報、社内情報、サーバーパス、認証情報は公開・共有前に伏せます。GitHub公式ロゴ、Octocat、公式画像もこのサイトでは使いません。
関連ページ
FAQ
CodexにGitHubのトークンを貼ってもいいですか？
貼らないでください。Personal Access Token、APIキー、Secret、SSHキー、認証情報はCodexに入力しない方が安全です。
private repositoryなら秘密情報を入れても安全ですか？
いいえ。privateでも共有範囲や権限、履歴、誤公開のリスクがあります。Secretsや.envの中身をそのまま置かないよう確認します。
CodexだけでPRをレビューできますか？
Codexは確認観点の整理に使えますが、最終レビューやマージ判断は人間が行います。