Skip to main content

Commits > Lines added

Tom Williams avatar
Written by Tom Williams
Updated this week

Dataset: Commits from pull requests

Entity: Commit

Field ID: additions

Type: Integer

Description: The number of lines of code added in the commit.

Source: App

From:

Github (Commits)

additions

Gitlab (Commits)

N/A

Bitbucket (Commits)

N/A

Azure DevOps (Commits)

Calculated from a git-based code diff

Jira

N/A

ClickUp

N/A

Trello

N/A

Why are lines of code not fetched for Bitbucket and GitLab?

Bitbucket and GitLab do not expose the number of lines of code changed on the commit API. To fetch the lines of code per commit, one must make an additional API call per commit (fetch the commit individually or the diff stats).
​
We do it for pull requests because the number of additional API calls remains reasonable (several thousand). However, commits could generate many additional API calls (several tens or hundreds of thousands), which would, in turn, contribute to reaching the Bitbucket throttling quota more quickly, potentially hindering data hydration (because the quota gets reached regularly).
​
So for now, the lines of code per commit are not retrieved for Bitbucket and GitLab. This decision might be revisited later on.

Reporting Use Cases

The Additions field from the Commits dataset provides a granular, commit-level view of the volume of new code being introduced. It is a powerful numeric field for analyzing individual developer contributions, understanding the nature of changes within a pull request, and creating detailed metrics on coding patterns.

  • Filtering by Commit Size: You can create highly specific reports by filtering commits based on their size.

    • Find Large Commits: Isolate individual commits that might be too large and difficult to review with a filter like Additions > 500. This can help in coaching developers to commit smaller, more atomic changes.

    • Exclude Scaffolding/Generated Code: If a large, auto-generated file is skewing your metrics for a pull request, you can create a report on that PR and then filter out the specific large commit to get a more accurate picture of the manual coding effort.

  • Analyzing Contribution Patterns: You can aggregate this field to understand the volume of new code being written.

    • Code Volume per Author: A bar chart with Author as the dimension and a SUM(additions) metric will show the total volume of new code each developer has written, providing a different perspective on contribution than just a simple commit count.

  • Custom Formulas for Advanced Analysis: This field is crucial for detailed, commit-level analysis of code health and style.

    • Commit-Level Refactoring Ratio: While usually measured at the pull request level, you can analyze refactoring at a micro level. A list of commits with a custom dimension like ROUND(deletions / IF_ZERO(additions, 1) * 100, 2) can show the refactoring ratio of each individual commit, helping to distinguish between "pure addition" commits and "refactoring" commits within the same PR.

Did this answer your question?