Azure DevOps Services · Git remotes and the REST API · Tested October 30, 2026

Azure DevOps Git remote URLs: dev.azure.com, visualstudio.com and DefaultCollection

Azure DevOps answers to two addresses, https://dev.azure.com/{organization} and the older https://{organization}.visualstudio.com, and repositories cloned over the years carry several shapes of clone URL. Most of them still work for git. Which ones do, what each part means, and where tools go wrong, tested with git ls-remote on public repositories, signed out.

Every form, tested

On October 30, 2026, on a public repository whose name is the same as its project's, and on one whose name is not:

https://dev.azure.com/{organization}/{project}/_git/{repository}: works. This is the form Azure DevOps hands out (the REST API's remoteUrl), with {organization}@ in front of dev.azure.com; that user name works too.
https://{organization}.visualstudio.com/{project}/_git/{repository}: works.
https://{organization}.visualstudio.com/DefaultCollection/{project}/_git/{repository}: works. On visualstudio.com, DefaultCollection in front of the project is skipped.
https://dev.azure.com/{organization}/DefaultCollection/{project}/_git/{repository}: fails, for git and for the REST API (an HTML "404 - Page not found"). DefaultCollection belongs only to the old host.
No project in the URL: https://{organization}.visualstudio.com/_git/{repository}, https://{organization}.visualstudio.com/DefaultCollection/_git/{repository} and https://dev.azure.com/{organization}/_git/{repository} all worked for the repository named like its project, and read the same commit as the full URL. For the other repository they failed: such a URL means "the repository named like its project", so the name of the repository is taken as the project's.
A .git suffix (…/_git/{repository}.git): fails. Azure Repos looks for a repository called {repository}.git.
Case does not matter: https://POWERSHELL.visualstudio.com/powershell/_git/powershell read the same repository as the original spelling.

A URL that fails this way does not say "not found" to someone signed out: git asks for a user name, because Azure DevOps answers a request for a private or missing repository with a sign-in. Signed in, the same mistake in the project part gives TF200016: The following project does not exist.

Over SSH the two hosts have their own forms, as the REST API gives them: git@ssh.dev.azure.com:v3/{organization}/{project}/{repository} and {organization}@vs-ssh.visualstudio.com:v3/{organization}/{project}/{repository}. Both always name the project. (Azure DevOps over SSH.)

Which address your organization uses

Every organization has a primary URL in one of the two forms. Organizations created on or after September 10, 2018 start with dev.azure.com, older ones with visualstudio.com, and an administrator can change it (Microsoft's Work with organization URLs). The primary URL is what pipelines see in SYSTEM_TEAMFOUNDATIONCOLLECTIONURI and what notifications and service hooks link to. Both forms keep working for git and for the REST API either way.

To look it up, no sign-in is needed:

GET https://dev.azure.com/_apis/resourceAreas/79134C72-4A58-4B42-976C-04E7115F32BF?accountName={organization}&api-version=5.0-preview.1

{"id": "79134c72-4a58-4b42-976c-04e7115f32bf", "name": "core", "locationUrl": "https://dev.azure.com/{organization}/"}

For a name that is not an organization, the same request got 404 and TF400677: Host … does not exist.

The REST API answers in the form it was called in. Asked on visualstudio.com, a repository's remoteUrl was https://{organization}.visualstudio.com/{project}/_git/{repository} and its sshUrl the vs-ssh.visualstudio.com one; asked on dev.azure.com, https://{organization}@dev.azure.com/{organization}/{project}/_git/{repository} and git@ssh.dev.azure.com:v3/…. Neither had DefaultCollection.

Switching a remote to dev.azure.com

See what the remote is now: git remote -v.
Copy the new URL from Repos > Files > Clone, or write it from the table above: drop DefaultCollection, put the project in if it was missing (the repository's name, when the URL had none), and leave off .git.
Set it: git remote set-url origin https://dev.azure.com/{organization}/{project}/_git/{repository}, then git fetch.

Nothing on the server changes, and the old URL keeps working for anyone who has not switched. Your credential helper stores sign-ins per address, so the first fetch from the new address may ask you to sign in once (Git Credential Manager 3.0 and Azure Repos).

Where tools go wrong

Tools that cut the path into pieces by position read the old forms wrong: DefaultCollection or _git taken for the project, or the URL not recognized as Azure DevOps at all. In public reports (2019 to 2026), editor extensions, a desktop coding app and dependency-update tools failed this way, often with TF200016. If one tool cannot find your repository and git can, check its remote: the dev.azure.com form with the project in it is the one every tool expects.

Azure DevOps pull requests in IntelliJ IDEA and Rider

Azure DevOps Pull Requests, a plugin by Lesstep for JetBrains IDEs 2024.1 or later and Android Studio, reads the organization, project and repository from your git remote in every form above that git accepts, the ones without a project included (from version 1.0.72), and from SSH remotes, then lists the pull requests that wait for your review in an IDE tool window, on Azure DevOps Services and on Azure DevOps Server. The review inbox and diffs are free; voting, commenting, completing and creating are Pro, with a 30-day trial.

Get it on JetBrains Marketplace

Azure DevOps and Visual Studio are trademarks of Microsoft Corporation; IntelliJ IDEA and Rider are trademarks of JetBrains s.r.o. This page is not affiliated with or endorsed by Microsoft or JetBrains.

More: TF200016: no project by that name · Azure DevOps over SSH · Git Credential Manager 3.0 and Azure Repos · 日本語