Exploring what Git history can tell us about how we work — without uploading data, dashboards, or black boxes.
For most of my career, Git history was something I used, not something I analyzed.
I’d inspect logs when debugging, skim commits when reviewing PRs, or glance at contribution graphs occasionally — but I never treated Git history as a meaningful signal about how I actually work over time.
That changed when I started feeling increasingly uncomfortable with modern developer analytics tools.
The problem with most developer analytics
Many tools promise deep insights into productivity and focus.
The pattern is usually the same:
- Upload your data
- Process it remotely
- Return a dashboard
- Add AI-generated interpretations
Even when these tools look polished, they often feel disconnected from how developers actually reason about their work.
As developers, we care about:
- Inspectability
- Determinism
- Owning our tools and data
But with analytics, we often accept:
- Opaque scoring
- Cloud-only pipelines
- Insights we can’t easily trace back to raw data
That led me to a simple question:
Do we really need AI and cloud processing to understand our own Git history?
Git history is already a rich signal
Git is more than version control.
It’s a chronological log of decisions.
Every commit contains information about:
- Scope and size of changes
- Frequency of context switches
- Where effort accumulates
- How work evolves over time
When viewed longitudinally, this becomes a surprisingly strong behavioral signal — without needing prediction or classification models.
And crucially:
this data already exists locally.
A strict constraint: everything runs locally
I decided to explore this idea under one hard rule:
All analysis must run locally.
No AI models.
No cloud processing.
No data leaving the machine.
This wasn’t an ideological stance against AI — it was about trust and clarity.
If an insight couldn’t be explained directly in terms of commits, timelines, and diffs, it didn’t belong.
Building GitGlow as an experiment
That experiment eventually turned into a tool I called GitGlow.
Initially, GitGlow was just a way to explore repositories differently:
- Time-based commit activity
- File-level change patterns
- Visual timelines instead of flat logs
But once I started using it on my own projects, I noticed things I hadn’t consciously tracked before:
- Long refactor-heavy periods with little outward progress
- High churn in specific files over time
- Changes in work cadence depending on project type
None of this felt “smart” or predictive — it was simply surfaced more clearly.
Observation instead of profiling
One thing I wanted to avoid was turning analytics into judgment.
GitGlow doesn’t try to label developers or score productivity.
Instead, it focuses on neutral observations, such as:
- Clustering of changes
- Shifts in commit size distribution
- Changes in activity regularity
These are signals, not conclusions.
Because everything runs locally, the experience feels closer to introspection than monitoring.
What I’m still figuring out
This approach raises open questions I’m still exploring:
- How much history is enough to make patterns meaningful?
- Where is the line between insight and over-interpretation?
- Which signals are genuinely useful, and which are just interesting?
I’m intentionally moving slowly here.
Tools that analyze how people work require a high trust bar — and trust is easier to lose than to build.
Why I’m sharing this now
This isn’t a product launch.
I’m sharing this because I think there’s room for developer tooling that is:
- Local-first
- Calm by default
- Inspectable
Built around observation, not prediction.
If nothing else, this experiment changed how I look at my own Git history.
The signal was already there.
I just needed to stop outsourcing the interpretation.
GitGlow exists today as a working experiment, and I’m continuing to explore where this direction leads. GitGlow
Top comments (1)
Appreciate you taking the time to read this.
I’m intentionally keeping GitGlow simple and local-first for now, so feedback on what feels useful vs. distracting would be super valuable.