# 変更履歴・変更管理ルールひな形（記入例）

架空企業「みらい業務サービス」の社内依頼・承認管理アプリの例。実在する会社・案件・人物は含まない。
記事「差分・保存単位・分岐・レビューで、変更履歴を安全に管理する」（06-03）の本文で実際に実行して確認した内容をまとめたもの。空欄版は `06-03-change-management_template.md`。

## 1. 最小の流れ（作業開始→分岐→変更→確認→add→commit→確認→やり直し）

| 段階 | 操作 | 確認したこと（2026-09-21 実行、evidence_public/phase5b2c2-2026-09-21/06-03/run_log.md） |
|---|---|---|
| 作業開始 | 変更前のコードを最初の保存単位にする | `git log --oneline` に1件 |
| 分岐 | `git switch -c fix-self-approval` | 分岐名が表示された |
| 変更確認 | `git status --short`、`git diff` | ` M approval.js` の1ファイル、`+  if (isSelf) return false;` の1行だけ |
| add・commit | `git add approval.js`、`git commit -m "自己承認を禁止する条件を追加（REQ-003）"` | エラーなし |
| 保存確認 | `git status --short`、`git log --oneline`、`git show --stat` | status 空、log に理由、`1 file changed, 1 insertion(+)` |
| やり直し | `git revert --no-edit HEAD` | Revert の保存単位が増え、ファイルは変更前と同一 |
| 共有先確認 | `git remote -v` | 出力なし（共有先なし） |

AIに変更させた後、保存の前に人が確認すること：変わったファイルが頼んだ範囲だけか（status）、変わった行が意図した変更だけか（diff）、保存の理由が何を・なぜを言えているか（log）。

## 2. 保存単位・変更理由の書き方

| 基準 | 内容 |
|---|---|
| 保存単位 | 1つの目的ごとに1つの保存単位とする |
| 変更理由の書き方 | 「何を」「なぜ（関連する要件ID）」を含める |
| 分岐の使い方 | 目的が分かる名前（例：fix-self-approval）。元の履歴を保ったまま試す変更、並行作業に使う |
| レビューの条件 | 保存の前に本人が status・diff を読む。共有先へ送る前に本人以外が差分を読む |

## 3. 共有先の扱い

| 項目 | 内容 |
|---|---|
| 送ってよい条件 | レビューを経た変更のみ |
| 禁止事項 | 秘密情報・実データを含む変更を送信しない |

## 4. 完了条件の確認

- [x] 変更前後の差分とやり直しの例がある（実際に実行）
- [x] 作業開始から保存の確認までの流れが通る（実際に実行）
- [x] 保存単位と変更理由の書き方が決まっている
- [x] 共有先へ送る条件と禁止事項がある

## 5. 次工程へ渡すもの

- [x] 変更履歴・変更管理ルール（第1〜3節）
- [ ] 承認者：総務課長（架空）— 記入例のため未承認の扱い