Table of Contents
Handling Squash Merges in LinearB
Learn how LinearB ensures accurate coding time metrics when squash merges are used, and how enabling Jira-based coding time can further improve tracking accuracy across your development workflows.
LinearB supports teams using squash merges by ensuring accurate metric reporting even when commit history is consolidated. Squash merges combine multiple commits into one, which can affect coding time calculations. To address this, LinearB detects and retains the earliest known pushed commit on a branch. This ensures coding time reflects actual effort, even after squash merges alter Git history. Teams using Jira can further enhance accuracy by enabling Jira-based coding time, which relies on workflow states rather than Git timestamps.
Understanding Git Squash
Git squash merges multiple sequential commits into a single commit. This is typically done before merging a feature branch into the main branch, resulting in a cleaner commit history. Squashing reduces clutter but also changes the commit timestamps, which can impact how development activity is tracked.
Impact on Coding Time Metrics
By default, LinearB calculates coding time based on the timestamp of the first commit made to a branch. When squash merges are used, all commit activity is consolidated into a single commit with a single timestamp. This can lead to inaccurate reporting—especially showing zero or minimal coding time—because the original individual commits are no longer visible.
LinearB’s Approach to Squash Merges
To ensure accurate metrics, LinearB performs the following:
- Earliest Commit Detection: LinearB records the earliest known commit on each monitored branch.
- If the squash merge hides earlier commits, LinearB will fall back to the earliest commit it has previously recorded—not just the commit history visible in Git post-squash.
- This method ensures that even squash-merged branches reflect accurate coding time, provided the earlier commits were pushed and tracked by LinearB before squashing.
Enhancing Accuracy with Jira-Based Coding Time
- Instead of relying solely on Git commit timestamps, LinearB begins measuring coding time based on when the linked Jira issue is moved to “In Progress.”
- This helps mitigate inconsistencies caused by squashing or rebasing, especially in teams that follow strict Git hygiene practices.
If your team uses Jira, you can enable Jira-based coding time, which shifts the calculation method:
How did we do?
Draft Pull Requests
Understanding Code Changes
