Git additions and deletions look obvious.
A commit adds some lines. It removes some lines. GitHub reports the totals.
But those two numbers can describe very different kinds of development depending on how they move together.
Additions and deletions are therefore most useful as raw ingredients for understanding change, not as standalone measures of productivity.
What an addition means
An addition records a line introduced into the tracked diff.
That can represent:
- new application code
- tests
- configuration
- documentation
- generated output
- dependency metadata
- infrastructure code
- copied or moved content that Git represents as new lines
The statistic does not know why the line exists or how difficult it was to produce.
It simply records the change visible in the diff.
What a deletion means
A deletion records a line removed from the tracked diff.
That can represent:
- cleanup
- refactoring
- feature removal
- migration
- obsolete code deletion
- file replacement
- generated-file changes
- repository restructuring
A deletion is not automatically loss.
Removing code can reduce maintenance burden, eliminate duplication, retire unused features, or complete a migration.
That is why additions and deletions should not be interpreted as "work created" and "work destroyed."
Read additions and deletions together
The relationship between the two numbers is more informative than either number alone.
Consider four broad patterns.
Many additions, few deletions
The codebase is expanding with relatively little replacement.
This can appear during new feature development, a new subsystem, or early-stage product construction.
Many additions, many deletions
A large amount of source is moving in both directions.
This can indicate refactoring, migration, rewriting, generated-code updates, or major architectural change.
Few additions, many deletions
The codebase is contracting.
That can happen during cleanup, consolidation, decommissioning, or a migration away from an older implementation.
Few additions, few deletions
The repository may be stable, lightly maintained, or inactive.
Context is required before deciding which explanation fits.
Net source growth shows direction
Additions and deletions can be combined into net source growth:
net source growth = additions - deletions
Suppose a month contains:
- 12,000 additions
- 7,000 deletions
Then:
12,000 - 7,000 = 5,000
The tracked source grew by a net 5,000 lines.
If deletions exceed additions, net growth becomes negative.
Negative net growth is not inherently bad. It may describe a successful simplification effort.
See How to Measure Source Code Growth Over Time for a fuller treatment.
Churn shows movement
The same two values can also produce code churn:
churn = additions + deletions
Using the same example:
12,000 + 7,000 = 19,000
That tells you how much source moved through the diff during the period.
Code churn is useful because two periods with identical net growth can have very different levels of rewriting.
Why additions alone can mislead
A dashboard that celebrates additions as output creates obvious problems.
Adding more lines can result from:
- duplicated code
- generated files
- unnecessary complexity
- large vendor updates
- verbose implementation choices
A small change can also be more valuable than a large one.
The number describes volume, not quality.
The same is true for deletions. Removing many lines may be excellent engineering, or it may simply reflect a generated artifact changing.
The metric cannot decide.
Renames and moves can affect interpretation
Git attempts to detect renames and similarities, but file movement can still affect how changes appear.
Large reorganizations can sometimes create addition/deletion patterns that look more dramatic than the conceptual change.
When a spike appears unexpectedly, inspect whether the period contained:
- file moves
- directory restructuring
- generated output
- formatting changes
- dependency updates
- mass renames
This is why aggregate metrics should be used as signals for investigation.
Generated files can dominate the totals
One generated client or lockfile can change thousands of lines.
That can overwhelm the statistics from handwritten source.
Examples include:
- generated API clients
- package lockfiles
- compiled bundles
- snapshots
- generated schemas
- vendored dependencies
If these files are tracked, they are legitimately part of the Git diff, but they may not represent the kind of source change you intended to analyze.
Large spikes should therefore be interpreted alongside repository knowledge.
Compare within the same repository first
Additions and deletions become easier to understand when you compare a repository with its own history.
For example:
- this month vs previous month
- this quarter vs previous quarter
- migration period vs pre-migration period
- active phase vs maintenance phase
Cross-repository comparisons are harder.
Ten thousand changed lines can be enormous for a compact library and routine for a large generated codebase.
Repository size, purpose, language, and workflow all matter.
Time range changes the meaning
A total of 30,000 additions can describe:
- one intense week
- a month of steady development
- an entire year of maintenance
Always attach additions and deletions to a clear date range.
7D, 30D, 90D, YTD, 1Y, ALL, and custom windows answer different questions.
Short windows expose bursts. Long windows reveal sustained direction.
Repository attribution makes aggregate totals useful
Account-level additions and deletions can hide which project caused the movement.
Suppose total deletions rise sharply.
The explanation could be:
- one repository being rewritten
- several projects being cleaned up
- one old codebase being removed
- a generated artifact changing repeatedly
Repository attribution turns a mysterious aggregate spike into something interpretable.
A useful analytics view should let you move from the account total to the repositories responsible for it.
Additions and deletions can reveal project phases
Patterns often align with lifecycle stages.
Early development may show strong positive net growth.
A migration may show high additions and high deletions.
A cleanup phase may show net negative growth.
A dormant phase may show almost no movement.
That is why source-change statistics pair naturally with repository lifecycle analytics.
Do not equate lines changed with effort
Some changes are large because they are mechanical.
Others are small because the difficult work happened before the final edit.
A one-line fix can require extensive debugging.
A 20,000-line generated update can require almost no manual editing.
Additions and deletions cannot observe:
- reasoning
- design difficulty
- debugging complexity
- research
- code review
- coordination
- architectural value
They are useful measurements of repository change, not effort.
A practical way to use additions and deletions
For a selected period:
- Record additions and deletions separately.
- Calculate net source growth.
- Calculate churn.
- Identify the repositories responsible for the largest totals.
- Compare with the previous equivalent period.
- Check for generated files, migrations, mass formatting, or repository restructuring.
- Compare the source-change pattern with active days and commit activity.
- Repeat over a longer window to see whether the change was temporary or sustained.
This keeps the analysis descriptive and grounded.
Two simple numbers, several useful questions
Additions and deletions are not sophisticated metrics.
That is part of their strength.
They provide a transparent record of how much tracked source entered and left a repository.
When paired with time, churn, net growth, and repository context, they can explain much more than a raw commit count.
Dev Ledger uses them as part of that larger historical picture rather than as a score.
For the broader workflow, see How to Analyze Your GitHub Development History.