---
name: git-commit-analysis
description: Deeply analyze git commit changes including code diffs, context snippets, and underlying reasons. Use when the user asks to analyze a git commit, review commit changes, understand code modifications, or investigate why changes were made.
---

# Git Commit Deep Analysis

## Overview

This skill guides you through performing comprehensive analysis of git commits, going beyond commit messages to understand:
- What code changed (detailed diffs)
- Why it changed (underlying reasons and purposes)
- Context around changes (surrounding code)
- Impact and implications

**Default behavior**: output the analysis directly in the chat. Do **not** create or write any Markdown report files (e.g. `COMMIT_ANALYSIS.md`) unless the user explicitly asks to save the output to a file.

## Analysis Workflow

### Step 1: Get Commit Information

First, retrieve the commit details:

```bash
# Get commit summary
git show <commit-hash> --stat

# Get full commit diff
git show <commit-hash>

# Get commit message only
git log -1 <commit-hash> --pretty=format:"%s%n%n%b"
```

### Step 2: Extract Changed Files

Identify all modified files and their change statistics:
- File paths
- Lines added/removed
- Change patterns (new files, deletions, modifications)

### Step 3: Deep Code Analysis

For each significant change:

1. **Read the changed code sections** with sufficient context (before/after)
2. **Read surrounding code** to understand the function/class context
3. **Compare with previous version** using `git show <commit-hash>^:filepath`
4. **Search for related code** that might be affected

### Step 4: Context Gathering

For each change location, read:
- **50-100 lines before** the change
- **50-100 lines after** the change
- **Related functions/classes** that interact with changed code
- **Similar patterns** in the codebase (use codebase_search)

### Step 5: Reason Analysis

Analyze why each change was made:

1. **Direct reasons**: What problem does this solve?
2. **Design decisions**: Why this approach vs alternatives?
3. **Business logic**: What business requirement drives this?
4. **Technical debt**: Is this fixing technical issues?
5. **Performance**: Does this optimize something?
6. **Maintainability**: Does this simplify code?

### Step 6: Impact Assessment

Evaluate:
- **Breaking changes**: Does this affect existing functionality?
- **Dependencies**: What other code depends on this?
- **Testing**: Are tests needed/updated?
- **Documentation**: Should docs be updated?

## Output Format

Structure your analysis as plain text sections (still delivered in the chat):

- Git Commit 深度分析报告
  - 提交信息：Commit Hash / 作者 / 日期 / 提交消息
  - 变更概览：文件清单、增删行统计、关键模块
  - 核心变更详细分析（按“变更点”分组）
    - 代码位置：文件 + 行号范围
    - 变更前片段：截取足够上下文（建议 50-100 行范围内的关键片段）
    - 变更后片段：同上
    - 上下文说明：这段代码在函数/流程中的角色、上下游数据/调用关系
    - 变更原因与目的：旧逻辑问题、新逻辑收益、业务驱动、技术权衡
  - 影响评估：兼容性、数据分布/阈值敏感性、性能、需要的验证/回归点
  - 总结：一句话目标 + 2-5 条高信号结论

## Key Analysis Principles

### 1. Go Beyond Commit Messages

Don't just read the commit message. Analyze:
- The actual code changes
- The context around changes
- Related code patterns
- Historical context (previous commits)

### 2. Understand the "Why"

For each change, ask:
- What problem does this solve?
- Why this solution vs alternatives?
- What constraints influenced the design?
- What trade-offs were made?

### 3. Provide Context

Always include:
- **Before/after code snippets** (not just diffs)
- **Surrounding code** (50-100 lines context)
- **Related functions/classes**
- **Usage examples** if applicable

### 4. Depth Over Breadth

For complex commits:
- Focus on **significant changes** (not every line)
- Provide **deep analysis** of key changes
- Group **related small changes** together
- Explain **interdependencies** between changes

### 5. Use Chinese for Analysis

When the user requests analysis in Chinese:
- Write all analysis in **简体中文**
- Use clear, technical Chinese terminology
- Keep structure clear and scannable (headings/bullets are fine). Avoid generating Markdown files unless requested.

## Code Reading Strategy

### For Each Changed Section:

1. **Read the current version** (after change)
   ```python
   read_file(target_file, offset=start_line-50, limit=change_size+100)
   ```

2. **Read the previous version** (before change)
   ```bash
   git show <commit-hash>^:filepath | sed -n 'start,end p'
   ```

3. **Search for related code**
   ```python
   codebase_search(query="How is this function used?", target_directories=[...])
   ```

4. **Read function/class definitions**
   ```python
   read_file(target_file, offset=0, limit=200)  # Read from start
   ```

## Common Analysis Patterns

### Pattern 1: Feature Addition
- **What**: New functionality added
- **Why**: Business requirement, user need
- **How**: Implementation approach
- **Impact**: New capabilities, potential breaking changes

### Pattern 2: Bug Fix
- **What**: What bug was fixed
- **Why**: Root cause analysis
- **How**: Fix approach and why it works
- **Impact**: Stability improvement

### Pattern 3: Refactoring
- **What**: Code structure changes
- **Why**: Maintainability, performance, clarity
- **How**: Refactoring techniques used
- **Impact**: Code quality improvement

### Pattern 4: Performance Optimization
- **What**: What was optimized
- **Why**: Performance bottleneck
- **How**: Optimization technique
- **Impact**: Performance metrics improvement

### Pattern 5: Architecture Change
- **What**: System design changes
- **Why**: Scalability, maintainability
- **How**: New architecture pattern
- **Impact**: Long-term system evolution

## Example Analysis Structure

For a typical commit with multiple changes:

```markdown
## 变更1: [Feature Name/Change Type]

### 代码位置和上下文
[Show where in the codebase]

### 变更前后对比
[Side-by-side or sequential comparison]

### 变更原因
1. **问题识别**: [What problem existed]
2. **解决方案**: [How this solves it]
3. **设计决策**: [Why this approach]

### 技术细节
- **算法/逻辑**: [Technical implementation]
- **数据结构**: [Data structures used]
- **性能考虑**: [Performance implications]

### 业务影响
- **功能影响**: [Feature impact]
- **用户体验**: [UX impact]
- **数据影响**: [Data impact]
```

## Quality Checklist

Before finalizing analysis, ensure:

- [ ] All significant changes are analyzed
- [ ] Code snippets include sufficient context (50-100 lines)
- [ ] Both before and after code are shown
- [ ] Reasons are explained, not just described
- [ ] Business and technical perspectives are covered
- [ ] Potential impacts are identified
- [ ] Related code is explored
- [ ] Analysis is structured and readable

## Tools to Use

- `git show` - Get commit diffs
- `git log` - Get commit history
- `read_file` - Read current code
- `codebase_search` - Find related code
- `grep` - Search for patterns
- `read_file` with offset/limit - Read specific sections

## Notes

- Always read **more context** than just the changed lines
- Compare with **previous version** to understand evolution
- Look for **related changes** in the same commit
- Consider **downstream effects** of changes
- Explain **trade-offs** and design decisions