DEV Community

ke jia
ke jia

Posted on

Git Analytics for the Solo Developer: Your Own Bus Factor

#git #cli #devops #javascript

Everyone talks about bus factor like it's a team problem. "What if the backend person gets hit by a bus?" — that's a question for orgs with more than one person.

Solo developers have the same problem with a worse answer: the bus is you, and there's no one else in the org to hit.

The good news is that git analytics works for a one-person repo, and it answers a different, more useful question: which parts of my code are single-points-of-failure in my own memory?

The check

Same command as for a team repo:

npx @wuchunjie/gitpulse .
Enter fullscreen mode Exit fullscreen mode

For a solo project, the contributor graph is boring — it's you, 100%. Ignore it. The useful blocks are the other three:

1. File type breakdown — where your mass is.

  File Type Breakdown
    .py    ############################ 214
    .sql   #### 38
    .md    ### 19
    .yaml  # 4
Enter fullscreen mode Exit fullscreen mode

The mass tells you where the complexity lives. If 70% of the mass is in one directory's worth of files, that's the part of the system that, if it breaks, breaks the product. For a solo dev, "the part that breaks the product" is the part you must understand the best, because there's no one to ask when it does.

2. Recent activity — what you were actually working on.

  Recent Activity
    2026-09-20  ################ 14
    2026-09-18  ######## 8
    2026-09-15  ##### 5
Enter fullscreen mode Exit fullscreen mode

Your recent activity is your current context. When you return to a project after a break — a week, a month, a quarter — the activity block tells you exactly where you left off, without relying on your memory of "I was doing the billing thing." The commits don't forget; you do.

3. Files touched — the hotspot list.

The files with the most churn are the files you're actively wrestling with. For a solo dev, high-churn files are a warning: you are reworking this repeatedly because the design isn't settled. A file touched 30 times in a month isn't "active development" — it's a design you keep fighting. That's the file to stop and think about, not the file to keep editing.

The solo-specific insight: your memory is the single point of failure

A team's bus factor is about people. A solo dev's is about knowledge location. The git history is the only external record of:

  • Why you made each decision (the commit messages, at their best)
  • What you tried and abandoned (the reverted commits, the dead branches)
  • When the system's shape changed (the big-diff days)

If you don't write the messages, the history is a list of what, not why — and the why is what you'll need most in six months, when the decision looks arbitrary. gitpulse doesn't fix that, but it surfaces the moments that had decisions: the big activity days, the churn hotspots, the mass shifts. Those are the commits where a "why" in the message would have saved you an afternoon.

The solo routine

I run it three times a month, two minutes each:

  1. Monday: gitpulse on the active project. Read recent activity — reorient to where I left off. Read the churn hotspots — identify the file I'm fighting.
  2. Mid-month: the file breakdown. Has the mass shifted? A new extension appearing (.wasm, .proto, a test framework's files) is a signal the project's shape is changing — sometimes intentionally, sometimes by accretion.
  3. End of month: the active-days count. For a side project, "am I actually building this, or just maintaining it?" is a question the activity graph answers honestly. A month of 2 active days on a side project is a signal to decide: commit to it, or archive it. Indecision is the expensive state.

The honest limit

For a solo dev, gitpulse can't tell you the code is good, the tests pass, or the architecture holds. It tells you the shape of your work: where the mass is, where the churn is, where the time went. Those are orientation facts, and orientation is the thing a solo dev most lacks — there's no standup, no teammate to ask "hey, what were you doing with the billing module?"

The history is the teammate. The tool makes it readable.

npx @wuchunjie/gitpulse
Enter fullscreen mode Exit fullscreen mode

More Tools

Tool What it does Command
scaffoldx-cli Production-ready project templates in seconds npx scaffoldx-cli
dotguard Scan .env files for exposed secrets npx @wuchunjie/dotguard
gitpulse Git repo analytics in your terminal npx @wuchunjie/gitpulse
snippetx Terminal code snippet manager npx @wuchunjie/snippetx

If these save you time, consider buying me a coffee. All tools are MIT-licensed, zero-dependency, and run fully offline.

Top comments (0)