Git issues with Azure DevOps Server (TFS 2018) using Visual Studio 2022 – Pull Request UI problems, deleted branches, and permissions [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Guide the asker to update the question so it focuses on a single, specific problem. Narrowing the question will help others answer the question concisely. You may edit the question if you feel you can improve it yourself. If edited, the question will be reviewed and might be reopened.

Closed 19 hours ago.

Improve this question

I’m working with Azure DevOps Server (TFS 2018, on-prem) and Visual Studio 2022, using Git repositories hosted on TFS.
I’m facing several issues that make Git hard to use reliably in this setup, especially from within Visual Studio.

1. Environment

   • Azure DevOps Server (TFS 2018, on-prem)

   • Visual Studio 2022

   • Git repositories

   • Windows

---

Issues

1. Pull Request button not working in Visual Studio

When I try to create a Pull Request from Visual Studio:

• The Create Pull Request button is visible

• Clicking it does nothing (no dialog, no error)

• Creating the Pull Request from the TFS Web UI works perfectly

This happens consistently, even after restarting Visual Studio.

---

2. Deleted branches still appear in Visual Studio

After completing a Pull Request and enabling "Delete source branch after merge":

• The branch is correctly deleted in the TFS Web UI

• However, the branch still appears under:

  remotes/origin/branch-name
  

  in Visual Studio

I tried:

• Fetch

• Refresh

• Restarting Visual Studio

But stale remote branches sometimes remain visible.

---

3. Inconsistent author names for the same user

In the commit history, the same person appears under different names, for example:

• Muhammed Alsaro

• Max-TechAi

Even though all commits are pushed by the same TFS user.
It appears Git is using user.name / user.email instead of the TFS identity, which leads to:

• Duplicate authors

• Messy history

• Harder auditing

---

4. Pull Request permissions confusion

Currently:

• The same user can create a Pull Request

• And also approve / complete their own Pull Request

I would like to enforce a workflow where:

• Developers can create Pull Requests

• But cannot approve or complete their own PR

• At least one other reviewer is required

However, it’s not clear which repository or branch permissions / policies should be configured in TFS 2018 to enforce this correctly.

---

Questions

1. Is the Pull Request button not responding in Visual Studio a known issue with VS 2022 + TFS 2018?

2. Is there a recommended way to clean/prune deleted remote branches from Visual Studio only (no command line)?

3. Is there any supported way to align Git commit identity with TFS users?

4. What is the correct way in TFS 2018 to:

   • Prevent users from approving their own Pull Requests?

   • Require at least one reviewer before completion?

5. From a practical standpoint, is Git fully recommended on TFS 2018, or is TFVC still the more stable option for on-prem environments?

• eftshift0: About point 2: in git-cli terms, you need to run git fetch --prune to delete the remote branches on a local repo.
• eftshift0: About point 3, the author of a commit is not decided when something is pushed... Commits are pushed as-is. The identity of the author/committer is set based on user.name and user.email (unless you use tricks to use different values) when a commit is created.
• jessehouwing: With regards to some features, like Create Pull Request not working, can be expected when the Visual Studio and TFS/Azure DevOps Server is more than 2 major versions apart: learn.microsoft.com/en-us/azure/devops/server/…
• jessehouwing: For full support upgrade the TFS server to Azure DevOps Server.
• jessehouwing: The difference in naming may happen when your display name in the Web UI hasn't been set. In that case merges and rebases may use the display name configured in the web and your local commits would use the local configuration on the workstation.

Answer 1

There's a lot to unpack here :). Let's address the elephant in the room, Team Foundation Server 2018 is "old" and is now in Extended Support mode. Visual Studio 2022 is much newer, 2017, 2019, 2020 and 2022 have come out since Team Foundation Server 2018 was released.

While Visual Studio 2022 officially supports Team Foundation Server 2018, there are more than 2 major versions between Team Foundation Server 2018 and the version that shipped with Visual Studio 2022, Azure DevOps Server 2022.

Microsoft documents that most features should work, but that a few of them might be broken:

General support

If a client is two versions older than your server, you can expect general support after you install a compatibility GDR. This support is similar to the high level of support you see when Visual Studio is one release older than Azure DevOps Server. The experience for some non-mainline scenarios might be degraded but not entirely blocked. Non-admins should be able to continue unimpeded in their daily work. Older process templates should remain compatible with the new server.

While I'd expect the Create Pull Request button to work, there are no guaranteed.

The best way forward is to upgrade Azure DevOps Server, a new version has just shipped, they have removed the year from the server version.

And Visual Studio 2022 has recently been superseded by Visual Studio 2026, it's more likely bug fixes will make it into Visual Studio 2026.

If you feel this is sufficiently broken, you can submit a bug on the Developer Community either under Azure DevOps Server or Visual Studio:

• Submit feedback for Azure DevOps Server / Team Foundation Server
• Submit feedback for Visual Studio

Now onto the other issues.

Prune remote branches

Every time you perform a git fetch (or git pull), git records the remote branches in your local git repo. And while branches are cleaned up on the server, git doesn't automatically clean them up on the client.

You can call git fetch --prune:

-p, --prune

Before fetching, remove any remote-tracking references that no longer exist on the remote. Tags are not subject to pruning if they are fetched only because of the default tag auto-following or due to a --tags option. However, if tags are fetched due to an explicit refspec (either on the command line or in the remote configuration, for example if the remote was cloned with the --mirror option), then they are also subject to pruning. Supplying --prune-tags is a shorthand for providing the tag refspec.

See the PRUNING section below for more details.

You can configure git to automatically prune remote branches through a config change every time you fetch.

git config remote.origin.prune true

Since Visual Studio calls git in the background, it will honor this setting.

You can also configure this setting in the Visual Studio 2022 settings (it will update your global git config on your behalf):

Source Control Settings in Visual Studio to set the prune branches option.

Git identity

There are a few things that might be going on with regards to the username display in Team Foundation Server.

1. Git captures the committer and uses the user.name and user.email settings. Visual Studio 2022 should be picking up these settings too.
2. The git configuration can be set at the system, user and repo level. This may cause different repositories to use different values.
3. Team Foundation Server also captures the pusher, it uses the authenticated identity (usually your Windows Identity), and ignores the user.email and user.name setting.
4. Team Foundation Server by default shows the identity as configured in Windows Active Directory.
5. If I remember correctly, users can change the way their name is shown in their profile settings on Team Foundation Server.
6. Certain actions in the web UI may create new commits: squash merge, rebase, editing files. Team Foundation Server will record the same profile name and profile email configuration.

I don't remember whether you can set these in the profile page in Team Foundation Server 2018, I'm certain you can in later versions:

Update the users name and email

There is no built-in way to sync these, most companies enforce these values from Windows Active Directory to begin with and some set the local git config settings from the Windows user sign-in scripts.

Branch Protections

To protect branches in Team Foundation Server, you need to setup a branch protection policy.

You can get to branch policy settings with Project Settings > Repository > Policies > Branch Policies > .

Select ... for the branch you want to protect target branch: open the context menu for the specific branch to protect it

You'd enable the Require a minimum number of reviewers policy and then make sure you leave the Requestors can approve their own changes unchecked.

Policy Configuration Screen

Later versions of Azure DevOps Server have better policy options, especially when multiple users are contributing to the same branch.

Git vs TFVC

Git has been the way to go for new repositories for a long time now. While TFVC is officially still supported, it can ben turned off in recent versions of Azure DevOps.

I've previously provided a long answer comparing TFVC and Git.

Your path forward should be Git. Not TFVC.