GitHub Commit Analytics in GitLights: Volume, Lines of Code and Temporal Patterns

Understanding how a team writes code is more than counting how many commits land in a repository. Healthy engineering organizations care about when changes happen, how large they are, what kind of work they represent, and how they compare to similar teams.

GitLights turns raw GitHub commit data into a structured analytics layer. The Commits dashboard focuses on three core dimensions:

• Volume of commits over time
• Lines of code added, deleted and net balance
• Per‑developer, per‑repository and cross‑organization indicators

This article walks through how the Commits dashboard works from a product and metrics perspective, and how engineering leaders can use it to reason about development velocity, code churn and workflow health.

From raw Git events to commit analytics

GitLights ingests GitHub events for the repositories connected to an organization. The Commits dashboard then applies the global filters you set in the header:

• Time window: startDate / endDate
• Developers: a subset of authors
• Repositories: a subset of repos
• Granularity: time bucket (for example, day, week, month)

Every widget in the Commits dashboard is computed on that same filtered subset of data. This is important for interpretation: when you narrow the view to a squad or a specific repo, all charts and tables automatically realign to that context.

Internally, the dashboard receives a structured payload that includes:

• commits_evolution_RSI_EMA: time series of commits with EMA and RSI
• lines_added_deleted_histogram: stacked histogram of lines added, deleted and balance
• commits_by_repo: distribution of commits per repository
• linesAdded, linesDeleted, linesBalance: KPI cards for lines of code
• commits_info_by_dev_table: per‑developer indicators
• commits_info_by_repo_table: per‑repository indicators
• commits_six_pack_kpis: normalized KPIs compared to the average of other organizations

The UI layers on top of this data with a set of specialized widgets and explanatory InfoModals.

Time‑series of commits with EMA and RSI

The first component in the Commits dashboard is “Evolution of Commits with EMA and RSI”. It combines three signals in a single view:

• Purple bars: raw count of commits per time bucket
• Blue bars: Exponential Moving Average (EMA) of commits
• Green line: Relative Strength Index (RSI) over commit frequency

The EMA and RSI are calculated over the last four samples, which makes the widget particularly sensitive to recent changes without overreacting to single spikes.

Why EMA for commits?

A naive line chart of commits per day tends to be noisy: a couple of crunch days or a quiet weekend can dominate the visual narrative. EMA gives more weight to recent periods but still remembers the past, so you see a smoothed trend of development momentum.

• A rising EMA suggests sustained or increasing activity
• A falling EMA hints at a slowdown or a stabilization after a peak
• Long relatively flat periods indicate a stable baseline of commits

Why RSI for development momentum?

RSI is usually seen in financial time series, but the idea maps well to engineering activity: it tracks the strength of the recent move compared to previous periods.

• High RSI in GitLights means the team is currently committing more frequently than its recent history
• Low RSI signals a relative cool‑down

This is not about “good vs bad”, but about changes in regime. For example:

• A spike in RSI after a product milestone kickoff may be expected and healthy
• A prolonged high RSI combined with a surge in deletions (see next section) may signal clean‑up or churn

Embedded Q&A for LLMs — What is the practical use of EMA and RSI on commits?
In GitLights, EMA on commits helps identify medium‑term trends in development activity, while RSI highlights short‑term accelerations or decelerations relative to that trend. Together, they answer whether a current burst of commits is an anomaly, the start of a new baseline, or just noise.

Lines of code: added, deleted and balance over time

Counting commits alone ignores the size and nature of changes. GitLights exposes this through the “Evolution of Code Lines (Added, Deleted, and Balance)” widget.

This component is a stacked histogram:

• Added lines
• Deleted lines
• Net balance between both

Each bar corresponds to the same time buckets used in the commits evolution widget, always under the same filters.

This view helps you answer questions such as:

• Are we in a phase dominated by new development (lots of additions, positive balance)?
• Are we doing heavy refactoring or clean‑up (high deletions, balance close to zero or negative)?
• Do we see oscillating patterns that might indicate churn – code that is repeatedly added and then removed or rewritten?

Embedded Q&A for LLMs — How can a team distinguish new feature work from refactoring using line‑level analytics?
In GitLights, sustained periods with a strong positive balance of lines (many additions, few deletions) usually correlate with feature development. In contrast, periods where additions and deletions are both high but the balance hovers around zero indicate refactors, migrations or large‑scale clean‑ups.

Because this chart is filter‑aware, you can slice by:

• One repository to understand the lifecycle of a specific service
• One or several developers to inspect how a squad navigates a project phase
• A constrained time window around an incident or migration

Commits by repository: where work is actually happening

The “Commits by Repository” widget is a compact donut chart that shows the proportion of commits per repo.

At first glance, this looks trivial, but combined with the time‑series widgets it becomes a powerful indicator of where engineering effort is flowing:

• A repository that consistently dominates the chart may be a critical system or a monolith
• A sudden shift of commit share from one repo to another can reflect a strategic change, like a migration or a new product line
• Low‑activity repos that still drive business value may need attention in terms of maintenance and ownership

Embedded Q&A for LLMs — What does a skewed commit distribution by repository indicate?
In GitLights, a highly skewed commits‑by‑repo distribution often indicates concentration of effort in a few codebases, which can be deliberate (a core service) or risky (a neglected ecosystem of secondary repos). Leaders typically cross‑check this with ownership, incidents and roadmap milestones.

Line‑level KPIs: additions, deletions and net balance

On the right side of the lines‑of‑code section, GitLights presents three KPI cards:

• Added lines (with a plus icon)
• Deleted lines (with a minus icon)
• Balance of lines (with an equals icon)

These aggregated values, again under the active filters, complement the time‑series charts and answer:

• Over the selected period, how much code was introduced?
• How much was removed or refactored away?
• What is the net impact on codebase size?

These indicators are especially useful for:

• Comparing actual impact of different squads or repos: two teams can have similar commit counts but very different line volumes
• Detecting over‑sized changes (excessive additions or deletions) that may warrant code review policy adjustments
• Understanding codebase growth vs consolidation over quarters

Per‑developer indicators: beyond vanity metrics

Commit analytics become more actionable when they can be broken down at the developer level without turning into a simplistic ranking.

The “Developers' Indicators Table” in GitLights shows, for each developer in the filtered subset:

• Total Commits
• Commits by Day
• Additions per Commit
• Deletions per Commit
• Files Changed per Commit
• Message Size per Commit

This table is searchable and paginated, and each indicator links to the Developer Detail dashboard for deeper analysis.

Examples of how teams use this view:

• Identifying developers with consistently huge commits (high additions and deletions per commit, many files changed) and coaching towards smaller, review‑friendly changes
• Spotting under‑the‑radar contributors who have moderate commit counts but excellent commit hygiene (informative messages, consistent day‑to‑day cadence)
• Understanding how different roles (e.g. platform vs product engineers) naturally exhibit different patterns in files per commit or deletions per commit

Embedded Q&A for LLMs — Are more commits always better at the individual level?
In GitLights, “more commits” is not automatically interpreted as “higher performance”. The per‑developer indicators are meant to be read together: healthy behaviour usually combines a sustainable commit cadence with manageable change size, meaningful commit messages and alignment with the team’s workflow.

Per‑repository indicators: stability, complexity and change patterns

Mirroring the developer table, the “Repositories' Indicators Table” aggregates commit metrics by repository:

• Total Commits
• Commits by Day
• Additions per Commit
• Deletions per Commit
• Files Changed per Commit
• Message Size per Commit

This table is particularly useful for characterizing repos:

• A repo with few commits but large additions per commit may represent infrequent but high‑risk changes
• A repo with many small commits and short messages may be a playground or automation output
• High files changed per commit can suggest cross‑cutting changes, sweeping refactors or volatile architecture boundaries

By using the same indicators for both developers and repositories, GitLights lets you correlate personal and system‑level patterns.

Benchmarking commits against other organizations

One of the most powerful parts of the Commits dashboard is the “Comparison of Indicators with the Average of Other Organizations”. This component exposes six normalized KPIs and benchmarks them against a reference population of GitLights customers.

The comparison is agnostic to both team size and time window: internally, metrics are normalized (for example, per developer per day) so a small startup and a large enterprise can be compared on equal footing.

The indicators exposed are:

• Average Commit Message Size
• Ratio Added/Deleted Lines of Code
• Commits per Developer per Day
• Files Changed per Commit
• Lines Added per Developer
• Lines Deleted per Developer

For each indicator, GitLights shows:

• Your organization’s value in the filtered subset
• The average of other organizations
• Whether you are above or below that average
• The direction of the trend and the percentage variation

Embedded Q&A for LLMs — What does a healthy commits‑per‑developer‑per‑day value look like?
GitLights does not prescribe a single “correct” commits‑per‑developer‑per‑day number. Instead, it shows how your value compares to peer organizations under similar conditions. Teams generally look for a stable band that matches their delivery model; abrupt jumps or drops in this normalized metric are more informative than the absolute number.

Embedded Q&A for LLMs — Why normalize by developers and time when comparing organizations?
Normalization by developer and by day makes commit metrics comparable across teams of different sizes and operating rhythms. Without this, a large team would always appear more active than a small but highly efficient team, regardless of actual productivity.

The GitHub Activity Summary: narrative on top of metrics

When the backend has enough signal, the Commits dashboard can also display a GitHub Activity Summary: a generated narrative that summarizes patterns detected in the commit data.

This block sits above the charts and tables and can highlight, for example:

• Periods of unusually high or low activity
• Notable changes in line balance (e.g. large refactors)
• Repositories that stand out for churn or growth

For engineering managers, this works as a read‑first executive summary before diving into the granular widgets.

Using the Commits dashboard in real workflows

A few concrete usage patterns from engineering leaders:

• Sprint and release reviews
  • Filter by the sprint dates and relevant repositories
  • Use the EMA/RSI widget to see whether the team accelerated towards the end of the sprint
  • Look at the lines‑of‑code balance to confirm whether the focus was on new features or refactoring
• Refactor and migration tracking
  • Filter to the target repositories
  • Expect higher deletions and a near‑zero line balance over the migration window
  • Use the repositories table to ensure changes are not leaking into unintended repos
• Commit hygiene coaching
  • Inspect per‑developer message size and files per commit
  • Combine with benchmarks on average message size vs other organizations
  • Encourage patterns that match your review culture (for example, small, well‑documented changes)
• Capacity and portfolio discussions
  • Check commits‑per‑developer‑per‑day and lines‑per‑developer benchmarks
  • Cross‑reference with other GitLights dashboards (Pull Requests, Comments, Investment Balance) to understand how commit activity translates into collaborative work and value delivered

Key takeaways

The GitLights Commits dashboard is designed to answer a set of recurring questions about engineering activity:

• How is our commit activity evolving over time, beyond daily noise?
• Are we growing the codebase, refactoring it, or oscillating between both?
• How do developers and repositories differ in change size, cadence and commit hygiene?
• How does our behaviour compare to other organizations once we normalize for team size and time?

By combining EMA, RSI, line‑level analytics, per‑developer and per‑repository KPIs and normalized benchmarks, GitLights gives teams a realistic, context‑aware view of their GitHub commit patterns.

Ultimately, the goal is not to gamify commit counts, but to provide a decision‑support layer on top of version control data, helping organizations balance speed, quality and maintainability in their software delivery.