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) | 
 | 
| 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 - Authoras 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.
 

