このページで整理すること
- Git連携の基本
- commit、diff、branch、PR
- 戻し方を先に考える
- 変更ファイル確認
- 秘密情報チェック
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上の差分と公開範囲を確認してから次の作業に進みます。
連携すると何が変わるか
Gitと連携しなくてもファイルは直せます。連携して変わるのは、作業そのものではなく作業のあとに残るものです。
| 連携しない場合 | 連携する場合 | |
|---|---|---|
| 変更内容 | 直したことは分かるが、何を変えたかは記憶頼み | 差分として残り、後から読める |
| 元に戻す | 自分でコピーを取っていなければ戻せない | 過去の時点を選んで戻せる |
| いつ変えたか | 分からない | 日時が自動で記録される |
| 不具合の調査 | いつから壊れたか特定できない | 変更履歴と症状の時期を突き合わせられる |
AIに作業を任せる場合、この差はさらに大きくなります。自分で書いていない変更ほど、後から何が変わったかを確認する手段が必要だからです。連携していないと、変更内容を把握しないまま本番が更新されていきます。
連携の前に決めておくこと
つないでから困らないよう、先に方針を決めておくと運用が安定します。
- 公開範囲：privateで始めるのが無難です。後からpublicへ変えるのは簡単ですが、逆は取り返しがつきません。
- 認証情報の扱い：パスワードやAPIキーは、ファイルに書かない前提で仕組みを作ります。一度履歴に入ると、後からファイルを消しても履歴には残ります。
- どこまでを対象にするか：サイト全体か、一部のディレクトリだけか。範囲を絞るほど、間違いが起きた時の影響も狭まります。
- 本番反映との関係：履歴に記録することと、公開サーバーへ反映することは別の操作です。混同すると「記録したのに反映されていない」状態になります。
最後の項目は初期につまずきやすい部分です。履歴に残す操作と、公開する操作は別物だと理解しておくと、「変更したのにサイトが変わらない」という混乱を避けられます。
秘密情報・公開範囲の注意
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は確認観点の整理に使えますが、最終レビューやマージ判断は人間が行います。