★ 初級

02. GitHub でチーム開発を完結させる

多くのチームの「事実上の標準」が GitHub。コード管理 / レビュー / CI / CD / Issues まで 1 プラットフォームで完結します。本章では GitHub の主要サービスを「コミット / ビルド / デプロイ」の流れに沿って整理します。

この章の目次

サービス全体図
Repository / Branches
Pull Request / Code Owners
Branch Protection
GitHub Actions (CI/CD)
Environments / Secrets
OIDC でクラウドにキーレスデプロイ
最小チーム構成

サービス全体図

GitHub の主要サービス：Repository / PR / Actions / Environments — コミット側は Repository + Branches、レビュー側は PR + Code Owners + Branch Protection、ビルドは Actions、デプロイは Environments + OIDC。

Repository / Branches

GitHub の Repository は「コードと履歴の保管庫」。チーム開発では次のブランチ戦略が一般的です。

ブランチ	役割	誰が触る
main	常にデプロイ可能な状態	マージのみ（直接 push 禁止）
feature/xxx	1 機能の作業ブランチ	担当者
hotfix/xxx	本番の緊急修正	担当者
release/x.y	リリース準備（任意）	リリース担当

Pull Request / Code Owners

Pull Request (PR) は「この変更を main に取り込んでください」という申請。差分が UI 上で表示され、コメントで質疑応答できます。

CODEOWNERS ファイルを使うと、特定のファイル / ディレクトリへの変更時に自動でレビュアーがアサインされます。

# .github/CODEOWNERS
# Terraform は infra チーム必須レビュー
*.tf                @org/infra-team

# フロントは frontend チーム必須レビュー
frontend/**         @org/frontend-team

# Actions ワークフローは平台チーム必須
.github/workflows/  @org/platform-team

Branch Protection

Branch Protection Rule で「main に何が必要か」を強制します。これがあるからこそ「PR を通さず main を壊す」が物理的に不可能になります。

PR 経由のマージのみ許可（直接 push 禁止）
承認 ≥ N 件（典型は 1 〜 2 件）
必須ステータスチェック（CI が成功していないとマージ不可）
会話の解決必須
linear history（マージコミット禁止 / squash 強制など）

GitHub Actions (CI/CD)

GitHub Actions は「リポジトリで起きたイベントに反応して何かを実行する」仕組み。YAML で定義します。

# .github/workflows/ci.yml
name: CI

on:
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - run: npm test
      - run: npm run build

このワークフローは「PR が main に向けて作成 / 更新されたら、test と build を回す」もの。失敗すれば PR にレッドのチェックが付き、Branch Protection があれば マージできなくなります。

Environments / Secrets

Environments は「デプロイ先」を表す概念。dev / stg / prod を分けて作るのが基本です。環境ごとに別の Secrets を持てるため、本番のクレデンシャルが PR の CI から漏れる事故を防げます。

Required reviewers: prod 環境への deploy は手動承認必須にできる
Deployment branches: prod は main からのみデプロイ可、など制限
Environment secrets: AWS_ACCESS_KEY_ID 等を環境ごとに分離

OIDC でクラウドにキーレスデプロイ

長期的なアクセスキーを GitHub Secrets に置くのは漏洩リスクが大きい。OIDC (OpenID Connect) を使うと、GitHub Actions ジョブから一時的なクラウド認証情報を取得できます。

# .github/workflows/deploy.yml
name: Deploy

on:
  push:
    branches: [main]

permissions:
  id-token: write   # OIDC トークン発行に必須
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/github-deploy
          aws-region: ap-northeast-1
      - run: terraform apply -auto-approve

クラウド側に「この GitHub リポジトリの main ブランチからの実行だけ信頼する」という IAM 設定をすれば、キーを 1 つも保管せずにデプロイできます（詳細は GitHub セクション 06）。

最小チーム構成

GitHub Organization を作る
リポジトリを作り、main の Branch Protection を設定
CODEOWNERS を置く
CI ワークフロー（PR で test/build）を書く
Environments で prod を作り、必要承認者を設定
クラウド側に OIDC ロールを作り、Actions から AssumeRole
main マージ → 自動で prod へ反映

これだけで「PR で必ずレビュー」「CI が通らないとマージ不可」「main マージで自動デプロイ」「prod 反映は手動承認」が成立します。