Skip to main content

Issues and PRs > Merged by

Tom Williams avatar
Written by Tom Williams
Updated today

Dataset: Issues & Pull Requests

Entity: Pull Requests

Field ID: merged_by_username

Type: Text

Description: The username of the person who merged the pull request. Note that usernames are app-specific.

Source: App

Transformation logic: N/A

From:

Github (PRs, Issues)

merged_by

Gitlab (PRs, Issues)

merged_by

Bitbucket (PRs)

closed_by only when PR state is merged (not closed)

Azure DevOps (PRs, Issues)

merged_by

JIRA (Issues)

N/A

ClickUp (Issues)

N/A

Trello (Issues)

N/A

Reporting Use Cases

The Merged By field identifies who performed the final action of merging a pull request, making it crucial for understanding your deployment process and auditing your release pipeline. As a text field, it is most often used for filtering and as a dimension to analyze merge responsibilities.

  • Filtering and Auditing: You can easily track merge activities and ensure compliance with your internal policies.

    • Track a Team's Merges: If you have a dedicated release team, you can create a report of all merges performed by them using a filter like Merged By equals any of "release-manager-1,release-manager-2".

    • Personal Activity: Use the is me operator to create a widget that shows all the pull requests you have personally merged.

    • Exclude Automated Merges: If you use bots to automatically merge pull requests (e.g., Dependabot), you can easily exclude them from your reports to focus on human-led activity with a filter like Merged By !~ "bot".

  • Reporting on Merge Responsibility: Using Merged By as a dimension helps visualize who is responsible for merging code.

    • A bar or pie chart with Merged By as the dimension and COUNT() as the metric can quickly identify who the primary "gatekeepers" of your codebase are. This can highlight if merge responsibilities are concentrated on a few key individuals, which could represent a process bottleneck.

  • Advanced Metrics: You can use this field within aggregations to get a higher-level view of your merge process.

    • Number of Mergers: A KPI with the custom formula COUNT_DISTINCT(merged_by_username) will tell you how many unique individuals are merging pull requests. A low number indicates a centralized release process, while a high number suggests a more decentralized, team-based approach.

Did this answer your question?