Sefism is free for learners. We are here to help you grow, one step at a time.Join for free
Sefism.
Other

Git Hotspot and Knowledge Risk CLI for Small Dev Teams

A command-line tool that mines a Git repository's history to find hotspots (files that change often and are complex), files only one person understands, and files that always change together, then prints a report a team lead can act on. A beginner-friendly developer tools final year project with real repositories as test data.

Topics
Difficulty

Beginner

Achievable by one student in a semester with familiar tools.
Effort

1 semester · 1 to 2 students

Deliverables

7 to ship

3 optional extras

Suggested stack

Python or GoGit log parsingLizard or Tree-sitter for complexitySQLite for cachingRich or Bubble Tea for terminal outputHTML report with Chart.js
A suggestion, not a requirement. Swap anything for what you already know.

What you should ship

  • A CLI that reads git log for a repository and a date range and computes per-file change frequency, lines added and removed, and number of distinct authors.
  • Hotspot ranking that combines change frequency with a code complexity measure, printed as a table and saved as JSON.
  • Knowledge risk: files and folders where one author wrote most of the recent changes, with a bus-factor summary per folder.
  • Change coupling: pairs of files that change together in the same commits above a threshold, with support and confidence scores.
  • Author alias handling so the same person with two emails is counted once, using a mailmap file.
  • A static HTML report with sortable tables and charts that can be attached to a pull request or shared with a lead.
  • An evaluation on at least five open source repositories, including a check of whether past bug-fix commits cluster in the files your tool ranks as hotspots.

If you have time left

  • A GitHub Action that posts the top hotspots touched by a pull request as a comment.
  • Trend view showing whether a hotspot is cooling down or getting worse over the last four quarters.
  • Ignore rules for generated files, lock files and vendored code, with sensible defaults.

The problem: teams do not know where their code hurts

Every codebase has a few files that everyone dreads: they change in almost every feature, they are long and tangled, and bugs keep coming from them. Every team also has files that only one developer truly understands, which becomes a crisis when that developer leaves or goes on leave. In software houses that rotate developers between client projects, this knowledge is lost constantly.

Team leads usually know this by feel, not by data. The data is already there: Git history records who changed what, when, and alongside which other files.

What already exists and the gap

  • code-maat by Adam Tornhill is an open source command-line tool that mines version control data for hotspots, coupling and ownership, used alongside his book on behavioural code analysis.
  • CodeScene automates and extends those analyses as a commercial platform with visualisations.
  • git-quick-stats prints simple contribution statistics from the terminal.
  • GitHub Insights shows contributor graphs, but not hotspots, coupling or file-level knowledge risk.

The gap is a single, easy-to-install tool that a student or a small team can run in one command, that explains its numbers in plain words, and that has been checked against real bug history to show its rankings mean something.

What you build

A CLI and a report.

  • Mine: run git log with numstat for the chosen range, parse it into commits, files, authors and line changes, and cache the result in SQLite so reruns are instant.
  • Measure complexity: for the current version of each source file, compute a simple complexity measure (cyclomatic complexity or indentation-based complexity, which works across languages).
  • Analyse: hotspots (change frequency times complexity), knowledge risk (share of recent changes by the top author), and change coupling (how often two files change in the same commit).
  • Report: a clear terminal table for quick use, plus a static HTML report with charts and short explanations of each metric.
  • Configure: ignore patterns, a date range, and a mailmap for author aliases.

The technically interesting part

The interesting part is making the analysis trustworthy. Git history is noisy: huge formatting commits, renamed files, merge commits, generated files and one person using three email addresses. Each of these distorts the numbers. You must decide how to follow renames, when to ignore a commit, and how to normalise so a 10,000-line migration does not dominate.

Then validate. Use commit messages to label bug-fix commits (words like fix, bug, crash, with a manual check of a sample), and test whether files your tool ranks as hotspots at a point in time receive more bug fixes in the following months. This turns a statistics script into a small empirical software engineering study.

How to evaluate it

  • Validity: on five or more open source repositories, compare bug-fix counts in the top 10 percent of hotspots against the rest; report the ratio.
  • Labelling accuracy: manually check 100 commits labelled as bug fixes and report precision.
  • Performance: time to analyse repositories with 1,000, 10,000 and 100,000 commits, cold and cached.
  • Usefulness: show reports to three team leads or open source maintainers and record whether the top hotspots match their experience.

Suggested plan

  1. Weeks 1 to 2: read about behavioural code analysis, choose test repositories.
  2. Weeks 3 to 5: git log parser, caching, author aliases and rename handling.
  3. Weeks 6 to 8: complexity measure, hotspot and knowledge risk metrics.
  4. Weeks 9 to 10: change coupling and ignore rules.
  5. Weeks 11 to 12: terminal and HTML reports.
  6. Weeks 13 to 14: bug-clustering validation, maintainer feedback and write-up.

Path to a product

Release it as open source on PyPI or Homebrew; developer tools grow through word of mouth. A paid layer could be a GitHub App that tracks hotspots over time for private repositories, priced per repository, sold to software houses and agencies that need to show clients the health of a codebase. Consulting-style "codebase health reports" for acquisitions or handovers are another realistic income path.

Scope warning

Do not build a web platform or dashboard server; a static report is enough. Do not rank individual developers by productivity; the tool is about code and knowledge distribution, not surveillance. Do not attempt deep static analysis for many languages; a language-agnostic complexity measure is fine.

Learn what you need on Sefism

Get help with this idea

This is a good first systems-flavoured project, and the bug-clustering check is what lifts it above a plain script. If you want a second opinion on scope, stack or how to evaluate it before you pitch it to your supervisor, bring your draft proposal and we will pressure-test it together. You build it; the guidance is on the decisions.

New here? Create a free account first.

Ideas and guidance, not finished projects

These are project ideas and scoping guidance, published free for students to use as a starting point. I do not build, write, or sell final-year projects, and I do not complete coursework for anyone. Take an idea, make it yours, and build it.

Not sure this one fits you?

I help students pick an idea that matches their skills and their deadline, then scope it down until it is finishable. Guidance only, never done for you.

Discuss this idea
Work with me

Stuck on something specific?

Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.

Book a free sessionSee all services

Follow along

New writing, resources and project ideas land here first.