Dataset: Issues & Pull Requests
Entity: Pull Requests, Issues
Field ID: first_commit_at
Type: Datetime
Description: The datetime at which the first commit was made on a pull request. For issues, it is the timestamp of the oldest commit across all resolving pull requests.
Source: Calculated from commits
Transformation logic:
Pull requests: It is the creation datetime of the first commit
Issues: It is the creation datetime of the oldest commit across all resolving pull requests. Resolving pull requests are pull requests that reference the issue via auto-closing keywords.
From: |
|
Github (PRs, Issues) | Calculated |
Gitlab (PRs, Issues) | Calculated |
Bitbucket (PRs, Issues) | Calculated |
Azure DevOps (PRs, Issues) | Calculated |
JIRA (Issues) | Inferred from PRs |
ClickUp (Issues) | Inferred from PRs |
Trello (Issues) | Inferred from PRs |
Reporting Use Cases
The First Commit At field is a critical timestamp that signals the true beginning of implementation work. It is essential for accurately measuring how long it takes for development to start and for calculating the duration of the coding phase in your cycle time analysis.
Calculating "Time to Start Coding": The primary use of this field is to measure the time between a task being assigned and the developer writing the first line of code.
You can calculate your team's "Time to Start" or "Time to First Commit" on issues with the custom formula
(first_commit_at - assigned_at) / HOUR(). A consistently high value for this metric might suggest that work is being assigned too far in advance or that developers are facing blockers before they can begin.
Improving Cycle Time Accuracy: For pull requests, the
Created Attimestamp doesn't always represent the start of coding. To get the most accurate start time for the entire PR lifecycle, it is best practice to use a formula that takes the earliest of the two dates.Robust Start Time: The formula
LEAST(created_at, first_commit_at)provides a reliable "start of work" timestamp, whether the developer commits code before creating the PR or vice versa. This is the recommended starting point for any overall "Lead Time for Changes" calculation on pull requests.
Filtering and Trend Analysis: You can use this field to analyze the efficiency of your team's intake process.
Identify Delays: While you cannot use formulas directly in filters, you can create a report with a custom dimension like
(first_commit_at - assigned_at) / DAY()to identify and analyze issues that had a long delay before implementation started.Track Triage Efficiency: By creating a line chart with
YEAR_MONTH(assigned_at)as a dimension andAVG(first_commit_at - assigned_at)/DAY()as a metric on issues, you can track whether your planning and triage processes are getting more efficient over time.