Share via

GitHub Pull Requests and Commits Not Appearing in Azure DevOps Work Item Development Section

Divyang Patel 0 Reputation points
2026-06-05T14:04:23.1433333+00:00

Hello Microsoft Support Team,

We recently migrated our source code repository from Azure Repos to GitHub while continuing to use Azure DevOps Boards for work item management.

Current Behavior

When the repository was hosted in Azure Repos, commits, branches, and pull requests were automatically displayed in the Development section of Azure DevOps work items.

After migrating to GitHub:

  • Azure Boards is connected to the GitHub repository.
  • Developers reference work items using the documented AB#<WorkItemId> syntax in commit messages and pull request descriptions.
  • The GitHub repository is successfully integrated with Azure DevOps.
  • However, GitHub commits and pull requests are not consistently appearing in the Development section of the associated work items.

Expected Behavior

We expect GitHub commits and pull requests to appear automatically in the Development section of Azure DevOps work items, similar to the behavior previously experienced with Azure Repos, as described in the Microsoft documentation.

References

Questions

  1. Is automatic population of the Development section for GitHub repositories fully supported today?
  2. Are there any known limitations, feature flags, or configuration requirements that differ from Azure Repos?
  3. Is the Development section expected to show GitHub commits and pull requests only when AB#<WorkItemId> is present, or are there additional prerequisites?
  4. Are there any known issues affecting organizations that migrated from Azure Repos to GitHub?
  5. Can Microsoft confirm whether the current behavior is expected, a configuration issue, or a product defect?

Environment

  • Azure DevOps Services (Cloud)
  • Azure Boards
  • GitHub Repository Integration
  • Previously using Azure Repos (where Development links worked as expected)

Additional Observation

The GitHub integration appears to be partially working. When a GitHub branch is created from the work item's Development section, the branch is displayed correctly. However, the related commits and pull requests are not automatically linked or shown in the Development section.User's image

We would appreciate guidance on the correct configuration or confirmation if this is a known issue.

Thank you.

Azure DevOps
0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Rakesh Mishra 9,670 Reputation points Microsoft External Staff Moderator
    2026-06-05T16:19:19.1433333+00:00

    Hello Divyang,

    Thank you for reaching out to Microsoft Q&A Portal. Migrating from Azure Repos to GitHub introduces some different behaviors for the Development section in Azure Boards.

    To answer your questions directly based on official Microsoft Documentation:

    1. Is automatic population of the Development section for GitHub repositories fully supported today?

    Yes, it is fully supported. After connecting Azure Boards to a GitHub repository, work items can be automatically linked to GitHub commits, branches, and pull requests.

    2. Are there any known limitations, feature flags, or configuration requirements that differ from Azure Repos?

    There are a few specific configuration requirements for the GitHub integration:

    • Mention Syntax Location: According to the official documentation, "Enter the AB#ID within the text of a commit message. Or, for a pull request or issue, enter the AB#ID within the description. Using AB#ID in a comment or pull request title doesn't create a link on the work item."
    • Single-Organization Constraint: As documented in the integration restrictions, "You can connect a GitHub repository to only one Azure DevOps organization and project. If you connect the same GitHub repository to projects defined in two or more Azure DevOps organizations, you might experience unexpected AB# mention linking."
    • Permissions: If using a Personal Access Token (PAT) for the connection, it must include the following scopes: repo, read:user, user:email, admin:repo_hook.

    3. Is the Development section expected to show GitHub commits and pull requests only when AB#<WorkItemId> is present?

    Yes, the primary automated way to populate the Development section is by using the AB#<WorkItemId> in the commit message or PR description. You can also manually link them from the Azure Boards work item by selecting Add link and choosing your GitHub commit or PR.

    4. Are there any known issues affecting organizations that migrated from Azure Repos to GitHub?

    A common issue post-migration involves legacy connections or Webhook misconfigurations. If the GitHub repo is inadvertently connected to an older Azure DevOps org (or multiple organizations simultaneously), the linking will fail or behave inconsistently.

    5. Can Microsoft confirm whether the current behavior is expected, a configuration issue, or a product defect? Since branches created from the work item are showing up, your basic connection is working. The missing commits/PRs likely point to a configuration issue regarding where the AB# tags are placed, or a webhook/PAT scope issue preventing the payload from reaching Azure DevOps.

    Next Steps / Troubleshooting:

    • Please confirm if the AB#<WorkItemId> is placed strictly within the body/description of the PR or commit message (and not just the title or comments).
    • Check your GitHub Connection status under Project Settings > GitHub connections. If there is an authentication error or alert, please try recreating the connection.
    • Verify that no other Azure DevOps organization is connected to this specific GitHub repository.

    Please let me know in comments if these checks resolve the issue or if you need further assistance!

    Note: This response is drafted with the help of AI systems.

    Was this answer helpful?

    0 comments

  2. AI answer

    2026-06-05T14:05:12.5866667+00:00

    Automatic population of the Development section from GitHub is supported, but it behaves differently from Azure Repos and has some important prerequisites and limitations.

    1. Is automatic population of the Development section for GitHub repositories fully supported today?
      Yes. After connecting Azure Boards to a GitHub repository, work items can be automatically linked to GitHub branches, commits, pull requests, and issues. This is done via the AB#<WorkItemId> mention syntax in GitHub commits and pull requests, and via links created from Azure Boards.
    2. Differences, limitations, or configuration requirements vs Azure Repos

    Compared to Azure Repos integration:

    • Connection requirement: The Azure Boards project must be connected to the specific GitHub repository that contains the commits/PRs. Only objects in connected repositories can appear in the Development section.
    • Single-organization constraint: A GitHub repository should be connected to only one Azure DevOps organization. Connecting the same repo to multiple organizations can cause unexpected AB# behavior and linking issues. The Azure Boards app for GitHub now prevents multiple-org connections; if the repo is connected to the wrong org, that connection must be removed first.
    • Authentication/permissions: The connection relies on either OAuth or a GitHub PAT. If the PAT is revoked, scopes are insufficient (repo, read:user, user:email, admin:repo_hook), or the user loses admin rights, work item mentions and links can fail or be delayed. In such cases, the connection shows an alert and must be removed and recreated.
    • Process model customization: For organizations using Hosted XML or on-premises XML process models, the work item type definitions must be updated so that GitHub link types appear in the Development section. Without this update, GitHub links may not show even if the integration is working.
    1. When does the Development section show GitHub commits and pull requests?
    • Using AB#<WorkItemId> in GitHub commits or pull request messages:
      • Fixed AB#123 / Fixes AB#123 / Fix AB#123 links the commit/PR to work item 123 and transitions it to the Resolved (or Completed) state category.
      • Closed AB#123 links and transitions to the Closed state (if defined).
      • Multiple IDs can be referenced; depending on the phrasing, either the first or all items are transitioned.
      • Mixed references like Fixing multiple bugs: issue #123 and user story AB#234 link both the GitHub issue and the Azure Boards work item but do not transition states.
    • AB# mentions in pull request descriptions also surface in the PR’s Development section in GitHub, and the corresponding links appear in Azure Boards when the integration is configured.
    • The Development control in Azure Boards aggregates these links for each work item; it shows linked branches, commits, pull requests, and builds.

    There are no additional hidden feature flags documented; the key prerequisites are: connected repo, valid auth/webhook, correct PAT scopes (if used), and updated work item type definitions for GitHub link types when using XML-based processes.

    1. Known issues for organizations migrating from Azure Repos to GitHub

    The documentation highlights these migration-related issues:

    • Broken or outdated callback/webhook URLs (especially when moving from Azure DevOps Server to Azure DevOps Services or changing organizations). In such cases, work item mentions in GitHub can be delayed or missing until the connection is removed and recreated or the webhook URL is updated.
    • Multiple-organization connections can cause unexpected AB# linking behavior because work item IDs are not unique across organizations.

    If the connection shows a red-X or indicates invalid credentials, the recommended action is to delete and recreate the connection so GitHub re-prompts for authorization.

    1. Is the current behavior expected, configuration, or defect?

    From the documented behavior:

    • It is expected that:
      • Only GitHub objects from connected repositories appear in the Development section.
      • AB#<WorkItemId> mentions drive linking and (optionally) state transitions.
      • XML-based processes require explicit updates to show GitHub link types in the Development section.
    • It is not expected that commits/PRs with correct AB# mentions from a properly connected repo simply never appear. When that happens, the documented causes are misconfigured or broken connections (PAT scopes, revoked access, outdated webhook URL, or multiple-org connections) or missing XML updates for GitHub link types.

    Given the partial behavior described (branches created from the work item appear, but commits/PRs do not consistently show):

    • Verify that the GitHub repo is connected to only one Azure DevOps organization.
    • Check the connection status in Azure Boards; if it shows an alert or red-X, remove and recreate the connection.
    • If using Hosted XML or on-premises XML process models, ensure the work item type XML definitions are updated so GitHub link types appear in the Development section.
    • Confirm that AB#<WorkItemId> is present in the commit or PR message (not only in titles or comments) and that the IDs correspond to work items in the connected project.

    If all these conditions are satisfied and the issue persists, the behavior would be inconsistent with the documented integration and should be treated as a potential product defect, to be escalated through official support channels.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.