第6章 GitHubのリポジトリ管理

ここからは GitHub の機能を中心に学んでいきます。
管理者として、リポジトリを 安全で効率的な開発環境 に整えるのが目標です 🏗️

この章のゴール

1. リポジトリの各種設定を適切に構成できる
2. Branch Protection Rules と Rulesets を使い分けられる
3. CODEOWNERS でレビュー体制を自動化できる
4. 3つのマージ戦略を理解し、チームに合った方式を選べる
5. PR / Issue の運用ルールを設計できる
6. GitHub Releases でリリースを管理できる

---

6.1 リポジトリ設定

Visibility（公開範囲）

設定	説明	使いどころ
Public	誰でも閲覧可能	OSS、ポートフォリオ
Private	メンバーのみ閲覧可能	社内プロジェクト
Internal	Organization 内で閲覧可能	社内共有ライブラリ（Enterprise のみ）

Visibility の変更は慎重に

Public → Private は即座に適用されますが、
Private → Public にすると 過去の全コミット履歴が公開 されます。
機密情報が履歴に含まれていないか確認してから変更しましょう。

テンプレートリポジトリ

新規プロジェクトの雛形として使えるリポジトリです。
Settings → Template repository にチェックを入れると、
「Use this template」ボタンが表示されます。

含めるべきもの：

• .gitignore / .gitattributes
• README のテンプレート
• CI/CD ワークフロー（.github/workflows/）
• CODEOWNERS
• Issue / PR テンプレート
• エディタ設定（.editorconfig）

リポジトリのアーカイブ

開発が終了したリポジトリは アーカイブ して読み取り専用にできます。
Settings → Danger Zone → Archive this repository

---

6.2 Branch Protection Rules

Branch Protection Rules とは？

重要なブランチ（main, develop など）を 誤った操作から守る ためのルールです。

flowchart TD
    A["開発者が main に
直接 push しようとする"]
    B{"Branch Protection
Rules"}
    C["❌ 拒否
PR 経由でマージしてください"]
    D["✅ PR 作成 → レビュー → マージ"]

    A --> B
    B -- "直接 push" --> C
    B -- "PR 経由" --> D

    style B fill:#FFF3E0,stroke:#FB8C00,color:#E65100
    style C fill:#FFEBEE,stroke:#E53935,color:#B71C1C
    style D fill:#E8F5E9,stroke:#43A047,color:#1B5E20

設定できるルール

ルール	説明
Require a pull request before merging	直接 push を禁止、PR 必須
Require approvals	指定人数のレビュー承認を必須に
Dismiss stale PR approvals	新しいコミットが push されたら承認をリセット
Require status checks to pass	CI のテストが通らないとマージ不可
Require branches to be up to date	ベースブランチの最新を取り込み済みであること
Require signed commits	GPG 署名付きコミットを必須に
Require linear history	マージコミットを禁止（squash or rebase のみ）
Restrict who can push	特定のチーム/ユーザーのみ push 可能
Do not allow bypassing	管理者もルールをバイパスできない

おすすめの設定例

flowchart TD
    subgraph "main ブランチの保護"
        R1["PR 必須 ✅"]
        R2["レビュー 2名以上 ✅"]
        R3["CI テスト通過必須 ✅"]
        R4["最新取り込み必須 ✅"]
        R5["force push 禁止 ✅"]
    end
    subgraph "develop ブランチの保護"
        R6["PR 必須 ✅"]
        R7["レビュー 1名以上 ✅"]
        R8["CI テスト通過必須 ✅"]
    end

    style R1 fill:#E8F5E9,stroke:#43A047,color:#1B5E20
    style R6 fill:#E3F2FD,stroke:#1E88E5,color:#0D47A1

---

6.3 Rulesets ─ 高度なルール管理

Branch Protection Rules との違い

項目	Branch Protection Rules	Rulesets
適用範囲	1リポジトリ	Organization 横断可能
重複ルール	1ブランチに1ルール	複数ルールを重ねられる
バイパス	管理者は自動バイパス	バイパスリストで明示的に管理
対象	ブランチのみ	ブランチ ＋ タグ
Push ルール	なし	フォークネットワーク全体に適用可能

今後の方向性

GitHub は Rulesets を Branch Protection Rules の 後継 として位置づけています。
新規プロジェクトでは Rulesets の使用を推奨します。

既存の Branch Protection Rules はそのまま動作し、Rulesets と 併用も可能 です。

Rulesets の作成

Settings → Rules → Rulesets → New ruleset から作成します。

設定の流れは以下のとおりです。

flowchart TD
    A["① Ruleset 名を設定"]
    B["② ステータス（Active / Evaluate / Disabled）"]
    C["③ バイパスリストの設定
(誰がルールを迂回できるか)"]
    D["④ ターゲットの設定
(どのブランチ/タグに適用するか)"]
    E["⑤ ルールの選択
(PR必須、署名必須、CI必須 etc.)"]

    A --> B --> C --> D --> E

    style A fill:#E3F2FD,stroke:#1E88E5,color:#0D47A1
    style E fill:#E8F5E9,stroke:#43A047,color:#1B5E20

Evaluate モードで試そう

新しいルールをいきなり Active にすると、チームの作業が止まる可能性があります。
まず Evaluate モード で「ルールに引っかかるケースはあるか」を確認し、
問題なければ Active に切り替えましょう。

---

6.4 CODEOWNERS

CODEOWNERS とは？

CODEOWNERS は、ファイルやディレクトリごとに 自動でレビュアーを割り当てる 仕組みです。
PR が作成されると、変更されたファイルに対応するオーナーが自動的にレビュアーに追加されます。

.github/CODEOWNERS

# デフォルトのオーナー（すべてのファイル）
* @your-org/core-team

# フロントエンドのコード
/src/frontend/       @your-org/frontend-team
*.tsx                @your-org/frontend-team
*.css                @your-org/frontend-team

# バックエンドのコード
/src/api/            @your-org/backend-team
/src/models/         @your-org/backend-team

# インフラ・CI/CD
/.github/workflows/  @your-org/devops-team
Dockerfile           @your-org/devops-team
docker-compose.yml   @your-org/devops-team

# ドキュメント
/docs/               @your-org/docs-team
*.md                 @taro-yamada

# セキュリティ関連（管理者が必ずレビュー）
.env.example         @your-org/security-team
/src/auth/           @your-org/security-team

パターンの書き方

パターン	マッチ対象
*	すべてのファイル
*.js	すべての .js ファイル
/docs/	ルート直下の docs ディレクトリ
src/	どの階層の src/ でもマッチ
/src/api/**	src/api 以下のすべて

CODEOWNERS の注意点

• ファイルの配置場所は .github/CODEOWNERS、CODEOWNERS、docs/CODEOWNERS のいずれか
• 最後にマッチしたルール が優先される（上から順に評価、後勝ち）
• Branch Protection で 「Require review from Code Owners」 を有効にしないと強制されない
• チーム名は @org/team-name 形式で指定

---

6.5 マージ戦略の理解

GitHub の3つのマージ方法

PR をマージする際、GitHub では3つの方法を選べます。

flowchart TD
    subgraph "Merge commit"
        M1["A - B - C (feature)"] --> MM["M (マージコミット)"]
        M2["D - E (main)"] --> MM
    end
    subgraph "Squash and merge"
        S1["A - B - C (feature)"] --> SM["ABC' (1つにまとめ)"]
        S2["D - E (main)"] --> SM
    end
    subgraph "Rebase and merge"
        R1["A - B - C (feature)"] --> RM["A' - B' - C' (付け替え)"]
        R2["D - E (main)"] --> RM
    end

    style MM fill:#E3F2FD,stroke:#1E88E5,color:#0D47A1
    style SM fill:#E8F5E9,stroke:#43A047,color:#1B5E20
    style RM fill:#FFF3E0,stroke:#FB8C00,color:#E65100

方法	履歴	マージコミット	おすすめ場面
Merge commit	全コミットが残る	作られる	履歴を完全に保持したい
Squash and merge	1コミットにまとまる	作られない	きれいな履歴を保ちたい
Rebase and merge	直線的に並ぶ	作られない	直線的な履歴にしたい

リポジトリでの設定

Settings → General → Pull Requests セクションで、
許可するマージ方法を設定できます。

チームでの統一がおすすめ

3つすべてを有効にすると、メンバーによってマージ方法がバラバラになります。
チームで1つか2つに絞る のがおすすめです。

よくある組み合わせ：

• Squash and merge のみ — main の履歴がきれいに保たれる
• Squash + Merge commit — 通常は Squash、大きな統合は Merge

---

6.6 Pull Request・Issue の運用設計

PR テンプレート

.github/pull_request_template.md

## 概要

<!-- この PR で何を変更しましたか？ -->

## 変更の種類

- [ ] 新機能 (feat)
- [ ] バグ修正 (fix)
- [ ] リファクタリング (refactor)
- [ ] ドキュメント (docs)
- [ ] その他

## 関連 Issue

<!-- Closes #123 -->

## テスト

<!-- どのようにテストしましたか？ -->

## スクリーンショット（該当する場合）

## レビュアーへのメモ

<!-- 特に見てほしいポイントなど -->

Issue テンプレート

.github/ISSUE_TEMPLATE/bug_report.yml

name: バグ報告
description: バグを報告してください
title: "[Bug]: "
labels: ["bug"]
body:
  - type: textarea
    id: description
    attributes:
      label: バグの内容
      description: 何が起きましたか？
    validations:
      required: true
  - type: textarea
    id: steps
    attributes:
      label: 再現手順
      description: バグを再現する手順を教えてください
      value: |
        1. ...
        2. ...
        3. ...
    validations:
      required: true
  - type: textarea
    id: expected
    attributes:
      label: 期待する動作
  - type: textarea
    id: actual
    attributes:
      label: 実際の動作
  - type: dropdown
    id: severity
    attributes:
      label: 深刻度
      options:
        - "低：軽微な問題"
        - "中：機能に影響あり"
        - "高：主要機能が使えない"
        - "緊急：本番障害"

PR / Issue のラベル設計

ラベル	色	用途
bug	🔴 赤	バグ報告
feature	🟢 緑	新機能
enhancement	🔵 青	改善
documentation	🟡 黄	ドキュメント
good first issue	🟣 紫	初心者向け
priority: high	🔴 赤	優先度高
status: in review	🟠 橙	レビュー中

---

6.7 リリース管理

GitHub Releases の活用

タグ作成と連動して、リリースノート を公開できます。

# タグを作成して push
git tag -a v1.2.0 -m "Release v1.2.0"
git push origin v1.2.0

# GitHub CLI でリリースを作成
gh release create v1.2.0 \
  --title "v1.2.0 - ログイン機能追加" \
  --generate-notes

# ファイルを添付する場合
gh release create v1.2.0 ./dist/app.zip --title "v1.2.0"

リリースノートの自動生成

GitHub は PR のタイトルとラベルから リリースノートを自動生成 できます。
.github/release.yml でカテゴリを設定しましょう。

.github/release.yml

changelog:
  categories:
    - title: "🚀 新機能"
      labels:
        - "feature"
        - "enhancement"
    - title: "🐛 バグ修正"
      labels:
        - "bug"
    - title: "📚 ドキュメント"
      labels:
        - "documentation"
    - title: "🔧 その他"
      labels:
        - "*"

---

まとめ

機能	管理者として確認すべきこと
Visibility	適切な公開範囲になっているか
Branch Protection / Rulesets	重要ブランチが保護されているか
CODEOWNERS	レビュー体制が自動化されているか
マージ戦略	チームで統一されているか
PR/Issue テンプレート	情報が漏れなく集まる設計か
リリース管理	バージョンとリリースノートが整備されているか

達成チェック ✅

• Branch Protection Rules と Rulesets の違いを説明できる
• CODEOWNERS ファイルを作成できる
• 3つのマージ戦略のメリット・デメリットを理解している
• PR / Issue テンプレートを整備できる
• GitHub Releases でリリースを管理できる

次は 第7章「GitHub Actions（CI/CD）」 に進みましょう！ 🎉