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:
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):
.
Git identity
There are a few things that might be going on with regards to the username display in Team Foundation Server.
- Git captures the committer and uses the
user.name and user.email settings. Visual Studio 2022 should be picking up these settings too.
- The git configuration can be set at the system, user and repo level. This may cause different repositories to use different values.
- 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.
- Team Foundation Server by default shows the identity as configured in Windows Active Directory.
- If I remember correctly, users can change the way their name is shown in their profile settings on Team Foundation Server.
- 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:
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:
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.
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.
git fetch --pruneto delete the remote branches on a local repo.user.nameanduser.email(unless you use tricks to use different values) when a commit is created.