How does LinearB handle squash merges?

What is Git Squash?

Git squash is a feature that allows developers to merge multiple sequential commits. The process involves choosing a base commit and merging all the changes from the sequential commits into the selected one.

Squashing produces one base commit, which contains changes from several selected commits.

How do squash merges affect your LinearB metrics?

By default, LinearB will calculate the coding time for a branch based on the timestamp of the first commit to a branch. If a development team is utilizing squash commits, all commit activity is packed into one commit with one timestamp. Because of this, branches that contain squash commits would appear to have a coding time of 0 if using the first commit listed in a branch's history. LinearB has two options for addressing this issue and finding a true coding time. (see below)

How does LinearB address squash merges?

LinearB records the "earliest commit" on branches it is monitoring. In cases where the earliest commit occurs before the reported first commit (indicating a squash merge has occurred), LinearB will instead fall back and report coding time based on the earliest commit detected.

Note that the earliest commit detected must be a commit pushed to a branch, LinearB cannot detect local commits.

Jira-based coding time

If your development team utilized Jira for your project management, you could enable LinearB's Jira-based coding time. This feature would begin calculating coding time for a branch based on when the Jira issue linked to a branch is set to "In progress". You can read more about how this feature works and how to enable this feature here: JIRA-based Coding Time