analyzing-git-sessions

Git セッションの分析

主な役割

指定された期間またはコミット範囲の Git アクティビティを構造化して分析します。コミット履歴、ファイル変更、統計、必要に応じて差分も含めます。

入力

ユーザーから次の情報を受け取ります。

• 期間：「過去 2 時間」「10 時から」「今日」「2025-10-23 14:00 以降」
• コミット範囲：「abc123..def456」「HEAD~5..HEAD」「feature-branch..main」
• 任意のフィルター：特定のパス、作成者、ファイル形式
• 出力の詳細度：簡潔（デフォルト）、詳細、またはコードレビュー形式

作業手順

ステップ 1：入力を解析して検証する

1. 範囲の種類を判定する：

   • 時間ベース：相対または絶対時刻を解析します
   • コミットベース：コミット参照が存在することを検証します
   • ブランチベース：ブランチ名をコミットに解決します

2. Git リポジトリを検証する：

   git rev-parse --git-dir
   

3. 範囲内にコミットがあることを確認する：

   git log <range> --oneline | head -1
   

   空の場合は、ユーザーに通知して終了します。

ステップ 2：コミット履歴を抽出する

# Get all commits in range
git log <range> --oneline --no-decorate

# Get detailed commit info
git log <range> --format="%h|%an|%ar|%s" --no-decorate

# Count commits
git log <range> --oneline | wc -l

要約用にコミットデータを保存します。

ステップ 3：統計を生成する

変更全体の統計：

# Summary stats (insertions/deletions by file)
git diff <start>..<end> --stat

# Numeric stats for parsing
git diff <start>..<end> --numstat

# Count total changes
git diff <start>..<end> --shortstat

作成者別の内訳（複数の作成者がいる場合）：

git shortlog <start>..<end> -sn

ファイルの分類：

• 新規ファイルを特定します（ステータス「A」で表示）
• 削除されたファイルを特定します（ステータス「D」で表示）
• 名前が変更されたファイルを特定します（ステータス「R」で表示）
• 変更量を含めて、変更されたファイルを示します

ステップ 4：詳細分析する主要ファイルを特定する

優先順位のルール：

1. 大規模な変更（変更行数が 100 行超）：必ず含めます
2. 新規ファイル：含めます（特に 50 行超の場合）
3. 削除されたファイル：記録しますが、差分は表示しません
4. アーキテクチャ関連ファイル：build.gradle.kts、AndroidManifest.xml、モジュール設定ファイル
5. テストファイル：テストカバレッジ評価用に個別に示します

主要ファイルのリストを抽出する：

# Files changed with line counts
git diff <start>..<end> --numstat | sort -rn -k1 -k2

コンテキストの過負荷を避けるため、デフォルトでは上位 10 ファイルに制限します。

ステップ 5：選択的に差分を生成する（詳細度に基づく）

簡潔モード：差分なし。統計のみ

詳細モード：主要ファイルの上位 3～5 件の差分

git diff <start>..<end> -- path/to/key/file.kt

コードレビュー モード：変更されたすべてのファイルの差分をモジュールごとにグループ化

# Group by directory
git diff <start>..<end> --name-only | cut -d'/' -f1-2 | sort -u

# Generate diffs per module
for module in modules; do
  git diff <start>..<end> -- $module/
done

コンテキスト過負荷の防止：

• 大幅に変更されたファイルが 10 件を超える場合、差分は上位 5 件に制限します
• ユーザーに警告します：「変更サイズ上位 5 ファイルを表示しています。差分全体が必要な場合は、特定のファイルを指定してください。」

ステップ 6：構造化された要約を提示する

詳細度に応じた形式：

簡潔な要約

## Git Session Summary

**Range**: <start-commit> to <end-commit> (<timeframe>)
**Commits**: X commits by Y author(s)
**Files Changed**: A modified, B added, C deleted
**Net Changes**: +X -Y lines

### Commits

- abc123 Commit message 1
- def456 Commit message 2
  ...

### Top Files Changed

1. path/to/file1.kt (+50 -20)
2. path/to/file2.kt (+30 -15)
   ...

詳細な要約

次の内容を含みます。

• 作成者とタイムスタンプを含むすべてのコミット一覧
• 変更統計を含むファイル一覧
• 作成者別の内訳
• レビュー用の上位 3～5 件の差分

コードレビュー形式

## Code Review Summary

### Overview

- **PR Title**: [Suggested from commit messages]
- **Changes**: X files across Y modules
- **Scope**: [Inferred from changed files]

### Commits

[Formatted commit list suitable for PR description]

### Changes by Module

**Module: app**

- file1.kt: Description of changes
- file2.kt: Description of changes

**Module: core**
...

### Key Changes

[Diffs for significant modifications]

### Test Coverage

- Test files modified: X
- New tests added: ~Y

出力ガイドライン

コミットメッセージ

• 短縮ハッシュ（7 文字）を表示します
• コミットメッセージの先頭行のみを表示します
• 長いメッセージは 80 文字に切り詰めます
• 複数のコントリビューターがいる場合は、作成者ごとにグループ化します

ファイルパス

• リポジトリルートからの相対パスを使用します
• コード形式で表示します：path/to/file.kt
• 変更行数を含めます：（+X -Y）
• ファイルの種類（ソース、テスト、設定）を明示します

統計

見やすい表で提示します。

| Metric        | Count |
| ------------- | ----- |
| Commits       | 15    |
| Files Changed | 23    |
| Insertions    | +450  |
| Deletions     | -180  |

差分

• ファイルパスをヘッダーとして含めます：### path/to/file.kt
• 構文ハイライト付きのコードブロックを使用します
• コンテキスト行を表示します（Git のデフォルト：前後 3 行）
• 非常に大きな差分（200 行超）は、要約を付けて切り詰めます

コンテキスト予算の管理

差分のサイズを監視する：

• 小規模なセッション（ファイル 10 件未満、変更 500 行未満）：詳細モードでも問題ありません
• 中規模なセッション（ファイル 10～30 件、変更 500～2000 行）：選択的に差分を表示します
• 大規模なセッション（ファイル 30 件超、変更 2000 行超）：警告を付けて簡潔モードを使用します

段階的な情報開示：

1. 必ず簡潔な要約から始めます
2. ユーザーに尋ねます：「特定のファイルの詳細な差分を表示しますか？」
3. 差分は最初から生成せず、要求に応じて生成します

大規模なセッションでの代替対応： 「このセッションでは 45 ファイルが変更され、変更行数は 5000 行を超えています。簡潔な要約を表示しています。詳細な差分が必要な場合は、特定のファイルまたはモジュールを指定してください。」

避けるべきアンチパターン

しないこと：

• 大規模なセッションですべてのファイルの差分を生成する（コンテキストがあふれます）
• 求められていないのに差分全体を含める（不要な詳細でコンテキストを浪費します）
• ファイルの種類を無視する（テストの変更とソースの変更を同じように扱います）
• ユーザーが知りたいことの文脈を見失う
• 具体性のない要約（「10 個のファイルを変更」など）を使用する

すること：

• 必要な詳細度をユーザーに尋ねる
• 変更規模に基づいて重要なファイルを優先する
• ファイルを分類する（ソース、テスト、設定、ドキュメント）
• 実行に移せる要約を提示する
• 特定のファイルについて詳しく説明できることを提案する

成功基準

優れた Git セッション分析は、次の条件を満たす必要があります。

1. 把握しやすい：ユーザーが変更の範囲をひと目で理解できる
2. 重点的：最も重要な変更を先に強調する
3. 次の行動につながる：詳しく確認するためのパスと差分を提示する
4. 効率的：不要な詳細でコンテキストを浪費しない
5. 柔軟：セッションの規模とユーザーのニーズに応じて詳細度を調整する

出力例

簡潔な要約やコードレビュー形式の詳しい例については、contexts/example-outputs.md を参照してください。