Git Repository Analytics

๐Ÿ“Š Git Analytics Dashboard

Transform your git data into actionable insights for better team performance

๐Ÿ“ˆ

Data-Driven Decisions

Make informed decisions about team capacity, workload distribution, and process improvements based on real commit data.

๐Ÿ‘ฅ

Team Health Monitoring

Track work-life balance, identify burnout risks, and ensure sustainable development practices across your team.

๐Ÿš€

Delivery Optimization

Measure lead times, track feature vs bug ratios, and optimize your development workflow for faster delivery.

๐ŸŽฏ Why Use Git Analytics?

1

Identify Bottlenecks

Spot code review delays, long lead times, and uneven workload distribution before they impact delivery.

2

Improve Code Quality

Track test coverage, ensure proper peer reviews, and maintain quality standards across all features.

3

Support Your Team

Monitor after-hours work, balance review loads, and create a healthier development environment.

4

Plan Better Sprints

Use historical data to estimate capacity, plan realistic timelines, and set achievable goals.

๐Ÿ“…

Weekly Reviews

Monitor team health and after-hours work patterns

๐Ÿ“ˆ

Monthly Analysis

Track delivery trends and adjust sprint planning

๐ŸŽฏ

Quarterly Planning

Assess productivity and plan process improvements

Ready to Get Started?

Set up your dashboard in under 5 minutes and start gaining insights immediately.

๐Ÿ“Š Monthly Activity

๐Ÿ‘ฅ Total Lines by Developer

๐Ÿ“Š What This Analysis Shows

  • Monthly Activity: Tracks code contribution patterns and identifies peak productivity periods
  • Developer Rankings: Shows relative productivity based on lines of code contributed (excluding merge commits)
  • Workload Distribution: Reveals how development work is distributed across team members
  • Productivity Trends: Identifies seasonal patterns, project phases, and individual performance cycles
  • Team Capacity: Helps estimate team velocity and plan future sprint commitments

๐Ÿ’ก Recommendations

๐Ÿ•˜ Monthly Business Hours vs Non-Business Hours

๐Ÿ‘ฅ Total Business Hours vs Non-Business Hours by Developer

๐Ÿ“Š What This Analysis Shows

  • Work-Life Balance: Tracks when developers are working outside standard business hours (8AM-5PM, Mon-Fri)
  • Burnout Risk: High after-hours percentages may indicate excessive workload or poor time management
  • Time Zone Patterns: Helps identify remote team members working in different time zones
  • Project Urgency: Spikes in weekend/evening work often correlate with project deadlines
  • Team Health: Sustainable development practices require balanced working hours

๐Ÿ’ก Recommendations

๐Ÿ“‹ Non-Business Hours Commits Reference

๐Ÿ“… Monthly Approvals

๐Ÿ“Š Approvals Distribution

๐Ÿ“Š What This Analysis Shows

  • Code Review Distribution: Shows how review workload is distributed across team members
  • Approval Patterns: Identifies who is reviewing what types of changes (features vs bugs)
  • Review Process Health: Ensures no single person becomes a bottleneck in the review process
  • Knowledge Sharing: Multiple reviewers indicate better knowledge distribution
  • Quality Assurance: Consistent review patterns help maintain code quality standards

๐Ÿ’ก Recommendations

๐ŸŽซ Ticket Reference

๐Ÿ“… Monthly Features & Bug Fixes

๐Ÿ“Š Features vs Bug Fixes Distribution

๐Ÿ“Š What This Analysis Shows

  • Feature vs Bug Ratio: Tracks the balance between new feature development and bug fixing work
  • Development Focus: Shows whether the team is primarily building new functionality or maintaining existing code
  • Quality Trends: High bug fix ratios may indicate technical debt or quality issues
  • Developer Specialization: Identifies who focuses on features vs bug fixes and maintenance
  • Sprint Planning: Helps estimate capacity allocation between new features and bug fixes
  • Product Health: Balanced ratios suggest healthy development practices

๐Ÿ’ก Recommendations

๐ŸŽซ Feature & Bug Fix Reference

๐Ÿ“… Monthly Test Coverage

๐Ÿ“Š Test Coverage Distribution

๐Ÿ“Š What This Analysis Shows

  • Test Coverage Gaps: Identifies tickets and commits that lack proper test coverage
  • Quality Assurance Patterns: Shows which developers consistently include tests with their changes
  • Risk Assessment: Highlights areas of the codebase that may be vulnerable due to insufficient testing
  • Testing Culture: Reveals team commitment to test-driven development practices
  • Technical Debt: Untested code represents potential future maintenance burden
  • Release Confidence: Higher test coverage correlates with safer deployments

๐Ÿ’ก Recommendations

๐Ÿšจ Tickets Without Tests

๐Ÿ“… Monthly Lead Time

๐Ÿ‘ฅ Lead Time by Developer

โฑ๏ธ Lead Time Breakdown (Dev vs Review Days)

๐Ÿ” Struggling Tickets Analysis

๐Ÿ“Š What This Analysis Shows

  • Development Velocity: Measures time from first commit to final merge, indicating team delivery speed
  • Multiple Merge Detection: Identifies tickets requiring multiple merges, indicating potential quality issues or incomplete work
  • Process Efficiency: Identifies bottlenecks in development workflow and review processes
  • Rework Analysis: Tracks additional development time after initial merge attempts
  • Quality vs Speed: Balances delivery velocity with code review thoroughness and rework patterns
  • Predictability: Helps forecast delivery dates considering potential rework cycles

๐Ÿ’ก Recommendations

โฑ๏ธ Lead Time Details

๐Ÿ“‹ How to Read the Numbers
15d Total Lead Time: First commit to final merge
8d dev Development Days: First to last commit
5d review Review Days: Last commit to final merge
3d rework Rework Days: Additional dev after first merge
2 merges Multiple Merges: Quality issues indicator

๐Ÿง  Knowledge Risk Analysis

Identify knowledge silos and bus factor risks in your codebase

๐Ÿ“ Analyze Module/Directory

Examples: src/auth, components/user, lib/utils, *.js

๐Ÿ“Š What This Analysis Shows

  • Bus Factor: Number of people who need to leave before knowledge is lost
  • Code Ownership: Who has made the most changes to this module
  • Risk Level: HIGH if one person owns >70%, MEDIUM if >50%, LOW otherwise
  • Knowledge Distribution: How evenly knowledge is spread across the team

๐Ÿ† Developer Rankings

Top 10 developers across all repositories

โš™๏ธ Dashboard Settings

Manage repositories and configure your analytics dashboard

๐Ÿ“

Repository Management

Add, remove, and manage your git repositories. Generate analytics data for each repository.

๐Ÿ”ง

Configuration Editor

Edit JIRA URLs, business hours, ticket patterns, and other dashboard configuration settings.

๐Ÿ“ Configured Repositories

โšก Quick Actions

๐Ÿš€ Multi-Repository Analytics Setup

Dockerized dashboard for analyzing multiple git repositories

1

Start Dashboard

Run the Docker setup:

./run.sh

Opens at http://localhost:3000

2

Add Repositories

Click "โš™๏ธ Manage Repos" and add your repositories:

  • Enter full path (e.g., /Users/john/projects/my-repo)
  • Give it a display name
  • Click "Add Repository"
3

Generate Analytics

Generate data for each repository:

  • Click "Generate Data" for each repo
  • Or use "๐Ÿ”„ Generate All Data"
  • Select repository from dropdown to view
๐Ÿ“Š Multi-Repository Support: Analyze multiple git repositories from one dashboard

Add repositories via "Manage Repos", generate data, then select from dropdown to view analytics.

โš™๏ธ Configuration Guide

๐Ÿ”— Organization Settings
JIRA_BASE_URL:
'https://yourcompany.atlassian.net/browse/'
TICKET_PATTERNS:
/(ABC-\d+|XYZ-\d+)/i
๐Ÿ• Business Hours
  • START_HOUR: 8 (8 AM)
  • END_HOUR: 17 (5 PM)
  • DAYS: Monday(1) - Friday(5)
๐ŸŒฟ Branch Prefixes
  • FEATURE: 'feature/'
  • BUGFIX: 'bugfix/'
  • HOTFIX: 'hotfix/'

๐Ÿ“ˆ Analytics Reference

๐Ÿ‘ฅ Contributors

Purpose: Track productivity patterns and workload distribution

Metrics: Lines of code, commits per month, developer rankings

Note: Excludes merge commits to avoid inflated statistics

๐Ÿ•˜ Working Hours

Purpose: Monitor work-life balance and identify burnout risks

Metrics: Business hours vs after-hours work patterns

Alert: High after-hours % may indicate workload issues

๐Ÿ” Peer Review

Purpose: Ensure quality through proper review distribution

Source: "Approved-by" field from merge commits

Use: Review process optimization, knowledge sharing

๐Ÿš€ Features & Bugs

Purpose: Track business value delivery vs quality issues

Classification: Based on branch prefixes (feature/, bugfix/)

Use: Sprint planning, stakeholder reporting

๐Ÿงช Test Coverage

Purpose: Identify testing gaps and quality practices

Detection: Commit messages with test file references

Use: Quality assurance, technical debt tracking

โฑ๏ธ Lead Time

Purpose: Measure development velocity and bottlenecks

Formula: PR merge time โˆ’ first commit time

Use: Process optimization, delivery forecasting

๐Ÿ”ง Troubleshooting Guide

โŒ Common Issues
  • "No repositories configured": Click "โš™๏ธ Manage Repos" to add repositories
  • "No data file found": Click "Generate Data" for the repository
  • "Repository path does not exist": Verify the full absolute path
  • No pull requests: Need "Approved-by:" in merge commits
๐Ÿ” Data Requirements
  • Peer Review: "Approved-by: Name" in merge commits
  • Features/Bugs: Branch prefixes (feature/, bugfix/)
  • Test Coverage: Test file mentions in commits
  • Lead Time: Regular + merge commits with PR #
๐Ÿ”„ Updating Data

To refresh with latest commits:

  • Click "Generate Data" button for specific repository
  • Or use "๐Ÿ”„ Generate All Data" to update all repositories
  • Data is automatically processed and stored

๐Ÿ”ง Technical Architecture

๐Ÿณ Docker Infrastructure
  • Containerized Node.js backend
  • Automated git data processing
  • Volume mounting for repository access
๐Ÿ“Š Multi-Repository Support
  • Centralized repository management
  • Individual data file generation
  • RESTful API for data operations
๐ŸŽจ Frontend Features
  • Interactive Chart.js visualizations
  • Responsive design for all devices
  • Real-time configuration editing

๐ŸŽฏ Best Practices & Guidelines

๐Ÿ“… Regular Usage
  • Weekly: Monitor team health & after-hours work
  • Monthly: Analyze delivery trends & adjust planning
  • Quarterly: Assess productivity & process improvements
๐Ÿ’ฌ Data Interpretation
  • Use metrics to start conversations, not make judgments
  • Consider project phases & individual circumstances
  • Focus on trends and patterns over absolute numbers
๐Ÿ”„ Data Quality
  • Maintain consistent commit message formats
  • Use standardized branch naming conventions
  • Regenerate repository data regularly for accuracy