How to fix TF402116: Push rejected because a work item is required in Git

GitBEGINNERMEDIUMUpdated Dec 6, 2025ยท 140 views

This error occurs when pushing to an Azure DevOps repository that has a branch policy requiring commits to be linked to work items. You must include a work item reference in your commit message or link work items through the Azure DevOps interface before pushing.

Quick fix

Fixes TF402116

git commit -m "Fix login validation bug #42"
  1. Add work item reference to your commit message
  2. Reference multiple work items if needed
  3. Fix existing commits without work item references
  4. Use a pull request instead of direct push
git โ€” error
git commit -m "Fix login validation bug #42"
TF402116: Push rejected because a work item is required

What this error means

When you push commits to an Azure DevOps Git repository, the server validates your push against configured branch policies. The TF402116 error indicates that the target branch has a policy requiring all commits to be associated with work items from Azure Boards. This policy helps organizations maintain traceability between code changes and tracked work items (user stories, bugs, tasks, etc.). When enabled, every commit must reference at least one work item to be accepted by the server. The error typically appears in these scenarios: - Pushing directly to a protected branch (main, develop, release branches) - Pushing commits that don't include work item references in their messages - Working in a repository where the "Check for linked work items" policy is set to Required - CI/CD pipelines attempting to push changes without work item associations

Typical symptoms

  • Git push fails with error TF402116
  • Error message mentions 'work item is required'
  • Push succeeds to some branches but fails on protected branches
  • Commits pushed from local environment are rejected by Azure DevOps
  • CI/CD pipeline fails when trying to push changes to the repository
  • Pull request merge is blocked due to missing work item links

Common causes

  1. Branch policy 'Check for linked work items' is set to Required on the target branch
  2. Commit messages do not include work item references (e.g., #123)
  3. Work items are not linked to the commits through Azure DevOps
  4. Pushing directly to a protected branch instead of using a pull request
  5. CI/CD pipeline does not include work item references in automated commits
  6. The referenced work item ID does not exist or is invalid

How to fix "TF402116: Push rejected because a work item is required"

1Add work item reference to your commit message

The simplest fix is to include a work item reference in your commit message using the hash syntax:

bash
git commit -m "Fix login validation bug #42"

Or if you need to amend your last commit:

bash
git commit --amend -m "Fix login validation bug #42"

Replace 42 with your actual work item ID from Azure Boards. The # symbol is required - Azure DevOps won't recognize bare numbers.

2Reference multiple work items if needed

You can link multiple work items in a single commit by including multiple references:

bash
git commit -m "Implement feature #123 and fix related bug #456"

Or use a more structured format:

bash
git commit -m "Add user profile page

Implements #123
Fixes #456
Related to #789"

All referenced work items will be automatically linked to the commit when pushed.

3Fix existing commits without work item references

If you have commits that need to be amended with work item references, use interactive rebase:

bash
# Rebase the last 3 commits (adjust number as needed)
git rebase -i HEAD~3

In the editor, change pick to reword for commits you want to modify:

bash
reword abc1234 Original commit message
pick def5678 Another commit

Save and close. Git will prompt you to edit each marked commit message where you can add the work item reference.

Warning: Only do this for commits that haven't been pushed yet, or coordinate with your team if rebasing shared history.

4Use a pull request instead of direct push

If the branch policy blocks direct pushes, use a pull request workflow:

1. Create a feature branch:

bash
git checkout -b feature/my-changes
git push -u origin feature/my-changes

2. Create a pull request in Azure DevOps and link work items in the PR interface

3. In Azure DevOps, navigate to Repos > Pull Requests > New Pull Request

4. In the Work Items section of the PR, click "Add work item" and search for the relevant work items

5. Complete the pull request to merge your changes

This approach is often preferred as it allows code review and provides better traceability.

5Link work items through Azure DevOps web interface

You can also link work items after commits are pushed (before PR completion):

1. Go to Azure DevOps > Repos > Commits
2. Find your commit and click on it
3. In the commit details, click "Link work items"
4. Search for and select the relevant work items

Alternatively, from the work item side:

1. Open the work item in Azure Boards
2. Go to the "Development" section
3. Click "Add link" > "Existing item"
4. Select "Commit" as the link type
5. Enter the commit SHA or browse to find it

6Enable commit mention linking in repository settings

If commit mentions aren't being recognized, verify the repository settings:

1. Go to Project Settings > Repositories
2. Select your repository
3. Under Settings, ensure "Commit mention linking" is enabled
4. Also enable "Commit mention work item resolution" if you want mentions to update work item state

Note: These settings may be disabled by default for forked repositories. If you're working in a fork, you may need to request these settings be enabled.

7Request bypass permissions (if appropriate)

In some cases, you may need to bypass the work item linking requirement:

1. Contact your Azure DevOps administrator
2. Request "Bypass policies when pushing" permission for the specific repository or branch

This permission allows you to push changes directly without meeting policy requirements. However, this should be used sparingly and only when necessary (e.g., emergency fixes, automated tooling).

To grant bypass permissions:
1. Go to Project Settings > Repositories > Security
2. Find the user or group
3. Set "Bypass policies when pushing" to Allow

Caution: Overusing bypass permissions defeats the purpose of having policies and reduces traceability.

Advanced notes

### Understanding Azure DevOps Branch Policies

Branch policies in Azure DevOps enforce quality standards and workflows. The work item linking requirement is one of several available policies:

- Require a minimum number of reviewers: Ensures code review before merge
- Check for linked work items: Enforces traceability (Required vs Optional)
- Check for comment resolution: Ensures all PR comments are addressed
- Build validation: Requires successful builds before merge

### Policy Configuration Options

The "Check for linked work items" policy has two modes:

1. Required: Pushes and PR completions are blocked without work item links
2. Optional: A warning is shown, but the operation is allowed

Administrators configure this at: Project Settings > Repos > Policies > Branch Policies > [Branch Name]

### CI/CD Pipeline Considerations

When automated pipelines need to push changes (version bumps, generated files, etc.), you have several options:

1. Use a dedicated work item: Create a recurring work item for automated changes and reference it in pipeline commits:

yaml
- script: |
       git commit -m "Automated version bump #999"
       git push

2. Grant bypass permissions to the build service account: The build service identity can be granted "Bypass policies when pushing"

3. Use pull requests from pipelines: Have the pipeline create a PR instead of direct push, with work items linked programmatically

### Commit Message Best Practices

Azure DevOps supports several formats for work item references:

- #123 - Basic reference
- Fixes #123 - Links and can transition work item state
- AB#123 - Explicit Azure Boards reference (useful in multi-system environments)

The commit message scanner looks for the # pattern followed by numbers. Include it anywhere in your commit message (subject line or body).

### Troubleshooting Tips

If work item links aren't being recognized:

1. Verify the work item ID exists and is accessible to you
2. Check that "Commit mention linking" is enabled in repository settings
3. Ensure you're pushing to the correct Azure DevOps organization/project
4. Try using the explicit format: AB#123

If you're getting this error in a pull request context, remember that work items must be linked to the PR itself, not just the individual commits. Work items linked to commits before creating the PR will auto-link, but adding work item references to commits after PR creation won't automatically update the PR.

Frequently asked questions

What does "TF402116" mean?
When you push commits to an Azure DevOps Git repository, the server validates your push against configured branch policies. The TF402116 error indicates that the target branch has a policy requiring all commits to be associated with work items from Azure Boards. ).
How do I fix "TF402116"?
This error occurs when pushing to an Azure DevOps repository that has a branch policy requiring commits to be linked to work items. You must include a work item reference in your commit message or link work items through the Azure DevOps interface before pushing.
What causes "TF402116"?
Branch policy 'Check for linked work items' is set to Required on the target branch Commit messages do not include work item references (e.g., #123) Work items are not linked to the commits through Azure DevOps
Is the "TF402116" error serious?
It is a medium-severity error โ€” more of a blocker than a risk. The steps above resolve it.

Official resources & further reading