GitAnalyzer
An explainable developer-feedback product that turns recent repository history into scoring, patterns, and practical recommendations.
Overview
GitAnalyzer turns recent GitHub commit history into an explainable repository report. It separates quality dimensions, surfaces recurring patterns, and gives maintainers and contributors a practical next action.
The product keeps the core analysis deterministic. AI is an optional assistance layer for commit-message improvement, not the authority behind the score.
- Role
- Product design and full-stack implementation
- System
- Developer-feedback platform
- Core boundary
- Deterministic analysis · Optional AI assistance
Problem
A commit history contains useful signals about how a repository is maintained, but raw logs make repeated quality problems difficult to see. Generic advice is also easy to ignore when it is not tied to the repository in front of the developer.
GitAnalyzer makes those signals legible without pretending that one score captures software quality as a whole.
Intended users
The primary users are developers reviewing their own commit habits, contributors learning a repository’s conventions, and maintainers who want a quick view of recurring commit-message patterns.
- A developer preparing a cleaner project history.
- A new contributor learning how a repository communicates change.
- A maintainer looking for repeated clarity, structure, or consistency problems.
Product walkthrough
Three connected views move from diagnosis to action: the scoring model explains the report, deterministic recommendations connect patterns to changes, and optional AI assistance works from a specific diff.
Clarity, structure, and consistency stay visible as separate signals instead of collapsing into an opaque score.
Clarity, structure, and consistency stay visible as separate signals instead of collapsing into an opaque score.
Detected commit patterns become focused guidance tied to the repository being analyzed.
Optional AI suggestions use the visible code change as context; the core analysis remains deterministic.
What I built
I implemented the analysis experience across repository input, API orchestration, scoring, recommendations, authenticated history, PDF reporting, and the optional AI suggestion path.
- Analysis
- Rule-based scoring across recent commit history
- Product
- Report, recommendations, history, and PDF workflows
- Identity
- GitHub and Google authentication
- Persistence
- Authenticated analysis history in Supabase
- AI boundary
- Diff-grounded suggestions with usage allowance and personal-key fallback
Architecture
The architecture deliberately separates reproducible analysis from optional generation. GitHub data enters a deterministic engine; repository patterns feed recommendations; authentication and history preserve reports; the AI path is invoked only for a selected diff.
GitHub APIFetches repository and recent commit data for analysis.
Important decisions
A single opaque score would be difficult to trust or improve against.
Expose clarity, structure, and consistency as separate signals.
The report takes more space, but the user can see why the summary changed.
Generative output can vary and should not determine the core report.
Keep analysis and recommendations deterministic; make AI assistance optional and diff-grounded.
The product has two related paths to explain, but the score remains reproducible.
Signed-in users need continuity while anonymous exploration should remain lightweight.
Store authenticated analysis history in Supabase and leave the public analysis flow focused.
Authentication and persistence add operational complexity in exchange for useful history.
Reliability and testing
The analysis path accounts for GitHub API loading and error states, limits the commit window, and keeps deterministic scoring independent from AI availability. Authenticated history and personal-key fallback reduce the number of dead ends in the product flow.
The most important regression boundary is the separation between analysis data and optional generation: a provider failure must not invalidate an otherwise complete repository report.
- Bounded recent-commit analysis.
- Explicit loading and API error states.
- Personal-key fallback after the monthly AI allowance.
- Persisted report history for authenticated users.
Challenges and trade-offs
Commit quality is contextual. The design therefore presents a useful heuristic rather than claiming an objective measure of engineering quality. Repository-level pattern detection is stronger when it stays explainable, but that also limits how much nuance a rules-only model can capture.
Current limitations
- The analysis is bounded to recent commit history rather than a repository’s full evolution.
- Commit-message heuristics cannot measure code correctness or business impact.
- AI suggestions depend on provider availability or a configured personal key.
- The scoring model will need continued calibration across different repository conventions.
Next improvements
- Add clearer repository-specific baseline comparisons.
- Expand regression coverage around large and unusual histories.
- Make scoring rules easier to inspect at the individual-commit level.
- Improve report export and shareable analysis states.