GitHubを見る前に
コード管理と秘密情報を分けて考える
GitHubはコード履歴や差分確認に向いています。APIキー、パスワード、DB情報などを置かないこともセットで確認しましょう。
まなぶちゃん
GitHubには何でも保存していいの？
GPTガイドくん
コード管理には便利ですが、秘密情報は入れません。差分を見るページと、入れてはいけないもののページを一緒に確認しましょう。
コードを見る差分を確認する秘密情報を避ける
このページで分かること
上級編では、GitHubを安全なチーム開発の土台として使う方法を整理します。ブランチ戦略、保護ブランチ、レビュー必須ルール、CI/CD、Secrets、環境ごとの設定、release / tag、セキュリティアラート、CODEOWNERS、Issueテンプレート、PRテンプレートなどを扱います。
チーム運用で決めること
- mainを保護するか
- レビューを必須にするか
- 誰がmergeできるか
- どのActionsを必須チェックにするか
- 本番反映の承認者を誰にするか
- ロールバック手順をどこに書くか
CI/CDとActionsの本格運用
CI/CDでは、テスト、ビルド、リンク確認、構文確認、デプロイ前確認を自動化します。便利な一方で、失敗した時の止め方、Secretsの扱い、環境ごとの権限、手動承認の有無を決めておく必要があります。
Secretsとリポジトリに入れてはいけないもの
Secretsは、ワークフローで使う秘密情報をリポジトリ本文に直接置かないための仕組みとして扱います。ただし、何をSecretsへ寄せるか、誰が見られるか、どの環境で使うかは人間が判断します。
- 認証情報をコードに直書きしない
- 本番設定を公開リポジトリに入れない
- 接続設定や秘密鍵をcommitしない
- Actionsログに秘密情報を出さない
- 権限は必要最小限にする
リリースとロールバック
releaseやtagを使うと、どの状態を公開したかを追いやすくなります。本番反映、DB変更、cron変更、.htaccess変更は影響範囲が広いため、PRレビュー、バックアップ、戻し方をセットで考えます。
Codexに頼む例
このリポジトリの運用ルールを確認し、main直変更を避けるためのPR運用、触ってはいけないファイル、Secretsに寄せるべき情報、GitHub Actionsで確認できる項目を整理してください。実装はせず、提案だけ出してください。上級確認チェックリスト
- 保護ブランチを検討した
- レビュー必須ルールを決めた
- Actionsの必須チェックを整理した
- Secretsの扱いを文書化した
- PRテンプレートがある
- Issueテンプレートがある
- CODEOWNERSを検討した
- release / tag の使い方を決めた
- ロールバック手順がある