Understanding Code Changes

Understanding Code Changes


Code changes is a metric that measures the changes that are done in the code base over time. It includes either new code or refactored code and is counted in a number of code lines that were changed over time.

Code changes are an important metric because it gives an indication regarding the size of a task and the risk level this task holds. The bigger the code changes number the higher risks that it presents. This metric is also important as one of the metrics that follow the throughput and productivity of individual/team/organization over time.


Just like with Work Breakdown, LinearB uses git blame to calculate the number of changes to a line of code. Because the entire commit chain leading up to the commit being evaluated is taken into account (rather than simply running a diff against the release branch of the code), the Code Change value should be accurate even if the last modification of a particular line was not merged back to the main release branch before being changed. This allows LinearB to track code changes that happen during the code review process, for example.


Let's say that above, orange represents our main branch and blue represents a feature branch. There were 4 commits to the feature branch before it was merged back to main. This consists of:

  • Commit 1 - Added 30 new lines of code
  • Commit 2 - Added 22 new lines of code
  • Commit 3 - Rewrote 5 of the lines added in Commit 2
  • Commit 4 - Deleted 10 lines added in Commit 1

Calculating changes:

  • Commit 1 - 30 changes
  • Commit 2 - 22 changes
  • Commit 3 - 5 changes
  • Commit 4 - 10 changes

This means that we would calculate this as 67 changes, even though there are only 42 new lines of code ultimately merged in to the main branch.

How did we do?

Powered by HelpDocs (opens in a new tab)