shield_lock
JinDaGe
← Back to skills
extension
Category: Development & EngineeringNo API key required

Git Risk Analysis

Analyze git history to enhance risk assessment for PR reviews. Use when analyzing file changes to detect code hotspots (high churn files), authorship patterns, historical failure correlation, and change complexity. Provides additional context beyond static code analysis to improve production risk scoring.

personAuthor: jakexiaohubgithub
open_in_newRepositorydownloadDownload package

Git Risk Analysis Skill

When to Use This Skill

  • ✅ Analyzing file changes in Pull Request reviews
  • ✅ Assessing risk of modifications to existing files
  • ✅ Need historical context for code stability
  • ✅ Enhancing risk scores with churn/hotspot data
  • ✅ Identifying files with deployment failure history

Git Metrics Analysis

🚨 CRITICAL EXECUTION RULES:

  • ALL git commands must run from project root using git -C workspace/{{REPO}}
  • Do NOT use pipe operators (|), compound operators (&&, ||), or redirects (>, 2>)
  • Do NOT use command substitution ($(...)) for variable assignments
  • Do NOT use text processing tools (wc, tr, awk, sed, sort)
  • Agent must count lines, deduplicate values, and parse output directly
  • Use Read tool to load metadata.json instead of jq command

1. Detect Code Hotspots (High Churn Rate)

Purpose: Identify files changed frequently (instability indicator)

Task: Count how many commits modified this file in the last 30 days BEFORE the current PR

⚠️ CRITICAL: Temporal Filtering Required

Use Read tool to load output/pr-{{PR_NUMBER}}/metadata.json and extract the pr_timestamp value.

Then run:

git -C workspace/{{REPO}} log main --since="30 days ago" --until="@{pr_timestamp}" --oneline -- <file>

Count the number of output lines in the agent to get the churn metric.

Why: Only analyze historical commits before the current PR to avoid temporal contamination (using future data to predict past risk).

Interpretation:

  • 0-3 commits = Stable file (LOW risk)
  • 4-10 commits = Moderate churn (baseline risk)
  • 10-15 commits = High churn → +10 risk score
  • 15+ commits = HOTSPOT → +20 risk score, flag as CRITICAL

Rationale: Research shows high churn correlates with poor implementation, missing abstractions, or inadequate tests. Hotspot files (20% of code) contain 80% of bugs.

2. Check Authorship Concentration

Purpose: Detect coordination risk from multiple contributors

Task: Identify how many unique authors have modified this file in the last 3 months BEFORE the current PR

⚠️ CRITICAL: Temporal Filtering Required

Use Read tool to load output/pr-{{PR_NUMBER}}/metadata.json and extract the pr_timestamp value.

Then run:

git -C workspace/{{REPO}} log main --since="3 months ago" --until="@{pr_timestamp}" --format="%ae" -- <file>

Deduplicate the output and count unique entries in the agent to get the authorship metric.

Interpretation:

  • 1-2 authors = Good ownership (LOW risk)
  • 3-4 authors = Coordination needed → Note in findings
  • 5+ authors = High coordination risk → +10 risk score

Rationale: Multiple authors increase merge conflicts, inconsistent patterns, and knowledge fragmentation. Coordination overhead grows exponentially with team size.

3. Find Historical Deployment Failures

Purpose: Identify files involved in production rollbacks/hotfixes

Task: Search git commit history BEFORE the current PR for messages containing keywords like "revert", "rollback", "hotfix", or "emergency" that affected this file

⚠️ CRITICAL: Temporal Filtering Required

Use Read tool to load output/pr-{{PR_NUMBER}}/metadata.json and extract the pr_timestamp value.

Then run:

git -C workspace/{{REPO}} log main --until="@{pr_timestamp}" --grep="revert\|rollback\|hotfix\|emergency" --oneline -- <file>

Count the number of output lines to determine if the file has rollback history.

❌ DO NOT USE: git log --all (includes future PR branches)

Interpretation:

  • 0 matches = No rollback history
  • 1+ matches = File has deployment failure history → Upgrade severity to CRITICAL
  • 3+ matches = Chronic production issues → Recommend architectural review

Rationale: Files with rollback history are statistically more likely to cause future production issues. Past failures predict future failures.

4. Measure Change Complexity

Purpose: Calculate lines changed (churn magnitude)

Task: Calculate the total number of lines added and deleted in this file over the last 30 days BEFORE the current PR

⚠️ CRITICAL: Temporal Filtering Required

Use Read tool to load output/pr-{{PR_NUMBER}}/metadata.json and extract the pr_timestamp value.

Then run:

git -C workspace/{{REPO}} log main --since="30 days ago" --until="@{pr_timestamp}" --numstat -- <file>

Parse the numstat output in the agent, sum the additions and deletions columns to calculate total lines changed.

Interpretation:

  • 0-100 lines = Small changes (LOW risk)
  • 100-300 lines = Moderate refactoring (baseline)
  • 300-500 lines = Large changes → +5 risk score
  • 500+ lines = Massive churn → +15 risk score, recommend incremental approach

Rationale: Large line changes increase bug probability. Smaller, incremental changes are safer for production.

5. Check Recent Bug Fix Rate

Purpose: Measure code quality via bug fix frequency

Task: Count commits in the last 60 days BEFORE the current PR that mention "fix", "bug", "issue", or "defect" in their messages for this file

⚠️ CRITICAL: Temporal Filtering Required

Use Read tool to load output/pr-{{PR_NUMBER}}/metadata.json and extract the pr_timestamp value.

Then run:

git -C workspace/{{REPO}} log main --since="60 days ago" --until="@{pr_timestamp}" --grep="fix\|bug\|issue\|defect" -i --oneline -- <file>

Count the number of output lines in the agent to get the bug fix rate.

Interpretation:

  • 0-1 fixes = Stable code quality
  • 2-3 fixes = Some quality concerns → Note in findings
  • 4+ fixes = Quality red flag → +10 risk score, recommend tests

Rationale: High bug fix rate indicates underlying quality issues. Files requiring frequent fixes often lack test coverage or have design flaws.

6. Detect Merge Conflict Frequency

Purpose: Identify files with complex merge history

Task: Count merge commits that affected this file in the last 2 months BEFORE the current PR

⚠️ CRITICAL: Temporal Filtering Required

Use Read tool to load output/pr-{{PR_NUMBER}}/metadata.json and extract the pr_timestamp value.

Then run:

git -C workspace/{{REPO}} log main --since="2 months ago" --until="@{pr_timestamp}" --merges --oneline -- <file>

Count the number of output lines in the agent to get the merge conflict frequency.

Interpretation:

  • 0-2 merges = Normal collaboration
  • 3-5 merges = Active development area
  • 6+ merges = High conflict risk → +5 risk score

Rationale: Frequent merges suggest parallel development streams, increasing conflict probability and integration issues.

Integration with Risk Analysis

Add Git Metrics to Findings

Include git context in your JSON output:

{
  "file": "src/services/PaymentService.java",
  "line": 45,
  "severity": "CRITICAL",
  "git_metrics": {
    "commits_last_month": 18,
    "unique_authors_3mo": 7,
    "lines_changed_30d": 750,
    "bug_fixes_60d": 5,
    "rollback_history": true,
    "merge_conflicts_60d": 8
  },
  "risk_adjustment": "+35 (hotspot + rollback history + high bug rate)",
  "original_severity": "HIGH",
  "adjusted_severity": "CRITICAL",
  "recommendation": "This file is a production hotspot with rollback history. Consider: 1) Architectural review before adding complexity, 2) Increase test coverage (5 bugs in 60 days), 3) Limit concurrent modifications (7 authors)"
}

Risk Score Adjustment Formula

Base Risk Score (from static analysis)
+ Churn Adjustment (0-20 points)
+ Authorship Adjustment (0-10 points)
+ Bug Fix Rate Adjustment (0-10 points)
+ Rollback History (upgrade to CRITICAL if present)
= Final Risk Score

Best Practices

✅ Do:

  • Run git commands from repository root
  • Handle missing files gracefully (new files have no git history)
  • Cache results to avoid redundant git calls
  • Consider context (1 commit from 1 author in a 5-year-old file is stable!)
  • USE TEMPORAL FILTERING: Only analyze commits BEFORE current PR timestamp ⚠️
  • Load PR timestamp from metadata.json before running git queries
  • Use main --until="${PR_TIMESTAMP}" for all git log commands

❌ Don't:

  • Fail entire analysis if git commands error
  • Run git commands on files outside the repository
  • Make assumptions about git configuration
  • Use --all flag or search future branches ⚠️
  • Include commits from PR branches that haven't been merged yet
  • Analyze data from future PRs (temporal contamination)

Example Risk Assessment

Scenario: Analyzing PaymentService.java in PR #1234

After gathering git metrics, you might find:

  • Churn: 15 commits in last month → HOTSPOT (+20 risk)
  • Authors: 4 unique contributors → Coordination concern (+5 risk)
  • Rollbacks: 2 rollback commits found → Deployment failure history (UPGRADE TO CRITICAL)
  • Bug fixes: 5 bug fixes in last 60 days → Quality concern (+10 risk)

Final Assessment:

  • Base severity: HIGH
  • Git adjustments: +35 points
  • Final: CRITICAL with strong evidence from git history

Success Criteria

Git analysis enhances risk scoring when:

  • ✅ Hotspot files get higher risk scores
  • ✅ Files with rollback history flagged as CRITICAL
  • ✅ Coordination risks identified for multi-author files
  • ✅ Bug-prone files get test coverage recommendations
  • ✅ Agent provides stability context in recommendations
  • ✅ 20-30% more accurate risk predictions

When NOT to Use

  • ❌ New files (no git history exists)
  • ❌ Non-git repositories
  • ❌ Files outside repository boundaries
  • ❌ When git commands timeout (very large repos)

In these cases, gracefully skip git analysis and rely on static code analysis only.