1.4 コミット履歴の読み方と設計

Git の履歴は、チームの 開発記録そのもの です。
きれいな履歴は「何がいつなぜ変わったか」をすぐに追えますし、
逆に散らかった履歴は、バグ調査やレビューの大きな妨げになります。

このセクションでは、コミット履歴を 読む力 と 設計する力 を身につけましょう 📖

コミットグラフを読む

コミットの構造

Git の各コミットは、以下の情報を持っています。

flowchart TD
    C["📦 コミットオブジェクト"]
    C --> H["ハッシュ値
a1b2c3d4e5f6..."]
    C --> P["親コミットへのポインタ
(どのコミットの次か)"]
    C --> T["ツリーオブジェクト
(ファイルのスナップショット)"]
    C --> A["メタデータ
作者 / 日時 / メッセージ"]

    style C fill:#FFF3E0,stroke:#FB8C00,color:#E65100
    style H fill:#E3F2FD,stroke:#1E88E5,color:#0D47A1
    style P fill:#E8F5E9,stroke:#43A047,color:#1B5E20
    style T fill:#F3E5F5,stroke:#8E24AA,color:#4A148C
    style A fill:#FFF9C4,stroke:#F9A825,color:#F57F17

コミットグラフの読み方

git log --oneline --graph --all

*   f3a1b2c (HEAD -> develop) Merge branch 'feature/signup'
|\
| * d4e5f6a (feature/signup) feat: サインアップフォーム追加
| * b7c8d9e fix: メールバリデーション修正
|/
* a1b2c3d feat: ヘッダーコンポーネント追加
* e4f5g6h (origin/main, main) 初期コミット

記号	意味
`*`	コミット
`\|`	ブランチの流れ
`\` `/`	分岐またはマージ
`(HEAD -> develop)`	現在いるブランチ
`(origin/main, main)`	ブランチポインタの位置

HEAD とブランチポインタ

flowchart LR
    HEAD["🎯 HEAD
今いる場所"]
    HEAD --> B["develop
(ブランチポインタ)"]
    B --> C1["コミット f3a1b2c"]
    C1 --> C2["コミット a1b2c3d"]
    C2 --> C3["コミット e4f5g6h"]

    style HEAD fill:#FFEBEE,stroke:#E53935,color:#B71C1C
    style B fill:#E3F2FD,stroke:#1E88E5,color:#0D47A1
    style C1 fill:#FFF3E0,stroke:#FB8C00,color:#E65100
    style C2 fill:#FFF3E0,stroke:#FB8C00,color:#E65100
    style C3 fill:#FFF3E0,stroke:#FB8C00,color:#E65100

用語	意味
HEAD	「今、自分がどこにいるか」を示すポインタ
ブランチ	特定のコミットを指す名前付きポインタ
タグ	特定のコミットに付ける固定ラベル（リリース用）

特定のコミットハッシュに直接 checkout すると detached HEAD 状態になります。
これは「どのブランチにも属していない」状態です。

# こうすると detached HEAD になる
git checkout a1b2c3d

# ブランチに戻る
git checkout develop

慌てずにブランチに checkout し直せば大丈夫です 😊

コミットメッセージの設計

なぜメッセージが重要なのか

コミットメッセージは 未来のチームメンバー（含む自分） が読むものです。
半年後に「なぜこの変更をしたのか」を知る唯一の手がかりになります。

Conventional Commits

Conventional Commits は、コミットメッセージに統一的な構造を与えるための規約です。
多くのチームやOSSプロジェクトで採用されています。

フォーマット

<type>(<scope>): <description>

[本文（任意）]

[フッター（任意）]

type 一覧

type	用途	例
`feat`	新機能	`feat: ユーザー登録機能を追加`
`fix`	バグ修正	`fix: ログイン時のエラーハンドリングを修正`
`docs`	ドキュメント	`docs: README にセットアップ手順を追加`
`style`	フォーマット変更	`style: インデントをタブからスペースに変更`
`refactor`	リファクタリング	`refactor: 認証ロジックを共通モジュールに抽出`
`test`	テスト	`test: ログイン機能のユニットテストを追加`
`chore`	ビルド・ツール	`chore: ESLint の設定を更新`
`perf`	パフォーマンス	`perf: 画像の遅延読み込みを実装`
`ci`	CI/CD	`ci: GitHub Actions のキャッシュ設定を追加`

scope（任意）

変更の影響範囲を括弧内に書きます。

feat(auth): OAuth2.0 によるログインを追加
fix(api): レスポンスのステータスコードを修正
docs(readme): インストール手順を更新

本文とフッター

複雑な変更の場合は、本文で 「なぜ」 を説明し、フッターで関連情報を記載します。

fix(auth): セッションタイムアウト時のリダイレクトを修正

ログアウト後にセッションが切れた状態で操作を続けると
500エラーが発生していた。タイムアウト検知時に
ログインページへリダイレクトするよう変更。

Closes #142
Co-authored-by: Hanako <hanako@example.com>

互換性のない変更がある場合は、type の後に ! をつけるか、フッターに記載します。

feat!: 認証APIのレスポンス形式をv2に変更

BREAKING CHANGE: /api/auth のレスポンスJSONの
構造が変更されました。詳細は migration-guide.md を参照。

コミットの粒度

適切な粒度とは

「1コミット = 1つの論理的な変更」が基本原則です。

✅ 良い粒度	❌ 悪い粒度
ログインフォームのHTML追加	3日分の作業をまとめてコミット
バリデーション関数の実装	関係ない複数の修正を1コミットに
CSSのレイアウト調整	ファイル1つの変更を5コミットに分割

判断のヒント

flowchart TD
    Q["この変更を一言で説明できる？"]
    Q -- "はい" --> A["✅ 適切な粒度"]
    Q -- "「〇〇と△△と□□を…」" --> B["⚠️ 分割を検討"]
    Q -- "「途中まで」「作業中」" --> C["⚠️ もう少し進めてから
コミットしよう"]

    style A fill:#E8F5E9,stroke:#43A047,color:#1B5E20
    style B fill:#FFF9C4,stroke:#F9A825,color:#F57F17
    style C fill:#FFF9C4,stroke:#F9A825,color:#F57F17

作業中は細かくコミットして、push 前に rebase -i でまとめる方法もあります。

# 細かくコミット（作業中）
git commit -m "wip: フォームの枠組み"
git commit -m "wip: バリデーション追加"
git commit -m "wip: エラー表示"

# push 前にまとめる
git rebase -i HEAD~3
# → 3つを1つの "feat: ログインフォーム追加" にまとめる

安心して細かくコミットできるので、おすすめの方法です ✨

まとめ

知識	ポイント
コミットグラフ	`--oneline --graph --all` で俯瞰する
HEAD	「今いる場所」を示すポインタ
ブランチ	コミットを指す移動可能なポインタ
Conventional Commits	`type(scope): description` の形式
コミット粒度	1コミット = 1つの論理的な変更