The question who actually maintains this codebase has a wrong answer that everyone gives and a right answer that takes one command. The wrong answer is the org chart: the team that owns the service, the people in the channel, the names in the ownership file. The right answer is in the git history, and it is not the commit count — it is the impact, which is what gitpulse measures: lines changed across distinct files, weighted by whether the files are hotspots, because a person who touches the debt magnets carries more of the codebase than a person who touches the leaves.
Run the command with a quarterly period and the output is a ranking that answers three questions at once. Who owns the hot files — the people who touch the debt magnets are the people the debt belongs to, and the debt follows the hands, not the org chart. Who is ramping — the new contributor whose impact curve is climbing is the person to pair with, not the person to assign a ticket to. And who is about to become a single point of failure — the person whose impact curve is flat while their commit count is high is doing a lot of small work in one place, and that place is now their name. The command is the same one; the reading is the skill, and this article teaches the reading, with the exact output shapes and the exact questions each shape answers. The map is the point; the command is how you get it.
I have written a lot of gitpulse content, but this is the one that answers the question people actually ask: how do you actually use it, step by step, from zero? No theory, no marketing. Just the commands, the output, and the decisions you will face along the way. If you have been meaning to try @wuchunjie/gitpulse and kept putting it off because the documentation felt like a commitment, this is the version that fits in one sitting. Git analytics in your terminal: file hotspots, commit patterns, branch strategy, contributor impact. — and everything below is what that actually looks like in practice, with the exact outputs you will see and the exact moments where the workflow forks.
What git log Can't Tell You
The log answers one question: who changed what, and when. It is a great question, and it is not the question. The question that actually predicts trouble is: where is the codebase accumulating damage? A file that changes forty-seven times a month is a hotspot no matter how clean each individual commit looks. A team whose commits cluster on late weekend hours is a team that is running hot no matter how green the pipeline is. The log shows you the events; the analytics show you the patterns underneath the events. That difference is the difference between a log and an analysis, and it is the reason a tool that reads your entire history and summarizes the shape of it is a different category of instrument from the version control system itself. The events are facts; the shape is the information. This article is about the shape, and about how to get it in thirty seconds instead of an afternoon of log-reading.
What Measuring Lots of Repos Taught Me
After running the same set of measurements across a large number of repositories — my own projects, client work, and public repositories from a range of stacks and team sizes — a few patterns held up consistently. Hotspots concentrate: a small fraction of files accounts for the majority of churn in almost every codebase. Commit patterns correlate with team size more than with team health: small teams look erratic, large teams look steady, and the middle is where the interesting data is. And the branch ratio is more stable over time than anyone expects — teams do not really change their shipping process, they change the people. The tool was designed to answer one question per repository. Measuring hundreds of repositories let the data answer a question I had not thought to ask: the shape of a codebase is more determined by its size and its people than by its technology, and the technology shows up mostly in the noise. The design decisions that followed — the default period, the impact weighting, the ratio as a headline metric — are all consequences of those patterns.
Contributor Impact: Measuring What Actually Ships
Commit count is the most common contributor metric and the least useful. A person who makes two hundred small commits to one file is not contributing two hundred times more than a person who makes twelve commits that each change a module. The analytics weigh contributions by impact: lines changed across distinct files, churn on hotspots, and the span of the codebase touched. The result is a much better answer to the onboarding question — who owns what — and the succession question — what happens if this person leaves. The tool is not a performance review; anyone who uses it that way is using it wrong. But it is a map of where the institutional knowledge actually lives, which is a map every team should have before it needs it. The impact ranking is that map: the people at the top are the load-bearing walls of the codebase, and knowing which walls they are is not management overhead. It is structural engineering.
Onboarding a New Repo in 60 Seconds
The worst moment in a developer's life is opening a repository they have never seen: no documentation, a multi-year history, and a codebase that looks the same in every folder. The analytics turn that moment into a sixty-second orientation. The hotspots tell you where the action is — start reading there, not at the README. The contributor impact tells you who to ask when the code does not make sense. The branch strategy tells you how changes actually get in, which is the one process fact that documentation never gets right. Inherited projects are the common case, not the exception: new job, new team, acquired codebase, open-source contribution. A tool that compresses the first hour into the first minute pays for itself on the first use. The sixty seconds buy you something rarer than time: a map, so the first day is spent building context instead of stumbling through directories hoping the important file announces itself.
Hotspots: Finding the Technical Debt Magnets
Every codebase has a handful of files that attract change the way a drain attracts water: the config that every feature touches, the utility that every module imports, the model that every migration reshapes. The analytics surface these as file hotspots — the files with the highest change frequency over your chosen period. The value is not the list itself; it is what the list tells you. A hotspot that is growing is a refactoring candidate with a priority attached. A hotspot that is stable is just a busy file. And a new hotspot appearing this month is an early warning that a design decision is about to become a migration project. Refactoring is cheaper when it is scheduled than when it is forced, and the hotspot list is the schedule. Read it monthly, and the debt magnets get addressed while they are still magnets instead of after they become the reason the release slipped.
The 30-Second Report
Run the tool with no arguments in a repository and you get the current month, summarized: the hot files, the commit shape, the branch behavior, the top contributors by impact rather than commit count. Thirty seconds from typing the command to having a picture of the repository that the log would take an hour to assemble by hand. The design goal was a report you would actually read, which means short enough to fit on a screen and dense enough that each line earns its place. I use it as a standing habit: first command of the week in any repository I am active in, the same way some developers start with status. The habit is the point. A report that takes ten minutes to generate gets run once a quarter. A report that takes thirty seconds gets run every Monday. The frequency is the feature, because the value of repository analytics is in the delta — what changed since last week — and the delta is only visible if you look often enough to see it move.
When Analytics Are the Wrong Tool
Honesty section: repository analytics are not for every repository. A new project with two weeks of history has no patterns to analyze — the hotspots are noise, the commit shape is just one person working, and the branch ratio is undefined. A solo project where you are the only contributor and you already know the codebase has little to tell you. And a repository where the team will use the output as a performance signal will get a distorted version of the truth, because the data was never collected for that purpose. The right use is a diagnostic: a repository you are inheriting, a repository that feels slower than it should, a repository you are about to present to stakeholders. Use it as a stethoscope, not as a scoreboard. The stethoscope tells you where to listen; the scoreboard tells you who to blame, and the blame is never in the data. Knowing which instrument you are holding is the whole skill, and the wrong instrument, used with confidence, is worse than no instrument at all.
Pairing gitpulse With dotguard in One Pipeline
A repository has two kinds of health: structural and security, and they are measured by different tools. One tells you whether the code is organized and maintained — hotspots under control, contributors distributed, branches reviewed. The other tells you whether the repository is leaking — secrets in configs, tokens in history, credentials in compose files. Running both in the same weekly pass is a complete repository health check in under a minute, and the outputs are complementary: a hotspot in a config file that the secret scanner also flags is a refactoring task with a security deadline. Two small CLIs, no shared infrastructure, one habit. That is the whole architecture of the pipeline, and it is the kind of architecture that survives because nothing in it needs to be maintained. The weekly pass becomes the meeting the team does not have to schedule: the file is the agenda, the findings are the action items, and the rotation of the week is the follow-up. Infrastructure this small is not a platform. It is a reflex, and reflexes are what teams actually keep.
The 2>/dev/null Bug: How I Learned to Test Where Users Are
A recent release was a fix for a bug that had been silently present for three months: a shell redirect that is fine on Linux and macOS and quietly wrong on Windows, where stderr handling behaves differently. The tool ran, produced output, and the bug only showed up as missing data for a subset of users on a subset of platforms. The lesson is not that I made a mistake. The lesson is that a CLI tool's test matrix has to include the platform where your users are, not the platform where you are. Three months of silent wrongness is longer than most bugs survive in a well-tested product, and the fix was one line. But finding it required a user report, not a test. That gap — between the platforms you test on and the platforms your users run on — is the most expensive gap in a cross-platform CLI, and it is the one that never shows up in your own usage because your machine is the one platform that always works. The fix was a line. The lesson is a test matrix.
Reading a Quarter: The Long View
The monthly view is for the pulse; the quarterly view is for the story. Extend the period to a quarter and you can see the arc of a release: the hotspot that built up through the quarter, the contributor who carried the middle two months, the week where the commit pattern broke. That view is where hiring and attrition show up. A new contributor ramping is visible as a growing impact curve. A person leaving is visible as a curve going flat, often weeks before the announcement. And a release that was supposed to be a sprint shows up as a commit pattern that never recovered. None of this requires a dashboard or a database. It is version control history, which you already have, read by a tool that knows which questions to ask. The quarter is the right window for most organizational questions, because a month is noise and a year is archaeology. A quarter is a story with a beginning and an end, and the report reads it for you.
Commit Patterns and the Burnout Signal
Commits have a rhythm, and the rhythm is a health metric. The analytics look at when commits happen — by hour, by day of week, by streak — and the pattern is more honest than any survey. A team that commits steadily on weekdays is one kind of team. A team whose commits spike on Friday nights and Saturday mornings is another, and the difference is visible in the data without asking a single person how they are doing. I am not saying commit timing equals wellbeing; it is a signal, not a verdict. But it is a signal that a manager who only looks at velocity will never see, and it is exactly the kind of information that is cheap to collect and expensive to guess at. The right use is the trend, not the snapshot: one busy weekend is a fact, four busy weekends in a row is a pattern, and the pattern is the conversation worth having, had with data instead of with hunches, before the hunches become resignations.
The takeaway
That is the whole workflow. npx @wuchunjie/gitpulse gets you started, and the repository at https://github.com/wuchunjie00/gitpulse has the full reference when you need it. If this saved you an hour, a coffee at ko-fi.com/wuchunjie keeps the tools free. And if you want the rest of the toolkit — dotguard for secret scanning, gitpulse for repository analytics, snippetx for snippets — the same npx pattern works for all of them. One command each, zero dependencies each, and a terminal that finally does the mechanical part of the job. The tutorial ends here; the habit starts now.
Top comments (0)