cloudparts

Azure Repos

Microsoft’s hosted Git repositories, part of Azure DevOps: pull requests guarded by branch policies that can require reviewers, linked work items and a passing build, plus the older centralized Team Foundation Version Control.

What it is
Version control
Type
Managed service on Azure
Made by
Microsoft
License
Proprietary
Facts checked
20 October 2026
Website

What it is

Azure Repos is one of the five services in Azure DevOps, next to Boards (work items), Pipelines (CI/CD), Test Plans and Artifacts. An organization holds projects, and a project holds repositories, cloned from URLs like https://dev.azure.com/<org>/<project>/_git/<repo>. Git in Azure Repos is standard Git, so any client works. The service adds pull requests, forks and branch policies. A policy on a branch such as main rejects direct pushes, so every change arrives as a pull request, and can require a minimum number of reviewers, linked work items, resolved comments, certain merge types, a build of the merged result (build validation), success statuses posted by outside services, and reviewers added automatically when certain paths change.

It also still offers Team Foundation Version Control (TFVC), the centralized system Microsoft shipped with Team Foundation Server in 2006. In TFVC developers usually have one version of each file locally, history lives only on the server, and branches are paths created on the server. Microsoft has added no TFVC features in recent years; since June 2024 a setting blocks creating new TFVC repositories, and Microsoft plans to phase TFVC out for new projects, though existing TFVC repositories keep working.

The Basic plan includes unlimited private Git repositories: the first five users are free, then $6 per user per month. A repository should stay under 250 GB (Microsoft recommends under 10 GB), single files under 100 MB, with Git LFS for larger ones, and each push under 5 GB. The same features ship in the self-hosted Azure DevOps Server, whose current release became generally available on December 9, 2025.

Why teams pick it

  • Branch policies gate merges on reviewers, work-item links, comment resolution, a pre-merge build and outside status checks, all configured per branch
  • Built into Azure DevOps: pull requests link to Boards work items and trigger Pipelines builds, under one organization and license
  • Proven on very large repositories: Windows moved to Git on it in 2017, about 3.5 million files and 300 GB
  • Cheap for small teams: five free users and unlimited private repositories, with a self-hosted server version for those who need one

Watch out for

  • Hard size limits: 250 GB per repository, 100 MB per file and 5 GB per push
  • TFVC is in maintenance: no new features, and Microsoft is phasing it out for new projects
  • Code hosting only: issues live in Azure Boards and CI in Azure Pipelines, separate services in the same product
  • Free Stakeholder users don’t get access to Git repositories; anyone who works with the code needs a Basic license

Alternatives

What all version control have in common →Compare side by side →
AWS CodeCommitAWSAWS’s managed Git hosting: private repositories inside an AWS account, with access controlled by IAM instead of separate user accounts, pull requests with approval rules, and triggers into other AWS services.Secure Source ManagerGoogle CloudGoogle Cloud’s managed Git forge: each customer gets its own single-tenant instance in one region, with repositories, pull requests, issues and branch protection, all behind Google Cloud IAM and private networking.

How it fits with other technologies

Create a repository, protect main and open a pull request with the Azure CLI · bash

az devops configure --defaults organization=https://dev.azure.com/acme project=Shop
az repos create --name web
git clone https://dev.azure.com/acme/Shop/_git/web && cd web

# main now needs two approvals; pushing new commits resets them
az repos policy approver-count create --repository-id <repo-id> --branch main \
  --minimum-approver-count 2 --creator-vote-counts false --allow-downvotes false \
  --reset-on-source-push true --blocking true --enabled true

git switch -c fix-login && git commit -am "Extend login session timeout"
git push -u origin fix-login
az repos pr create --source-branch fix-login --target-branch main \
  --title "Extend login session timeout" --auto-complete true

See it in a real stack

No architecture uses Azure Repos yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2006–2025

Microsoft shipped its first Team Foundation Server, TFS 2005, on March 17, 2006, about six months late and after a little more than three years of work. Its version control, code-named Hatteras, was centralized: the server held the history and developers checked files out from it.

In February 2013 Microsoft added Git hosting to its cloud service, Team Foundation Service, with a Visual Studio add-in, and planned Git support for the on-premises Team Foundation Server 2013. Brian Harry, who ran the product, said the aim was to offer “the best distributed version control experience” alongside “the best centralized version control experience”, and to make Git “enterprise grade” while staying compatible with standard Git. In 2017 Microsoft moved Windows itself to Git on the service, by then called Visual Studio Team Services: about 3.5 million files, a repository of about 300 GB, and some 4,000 engineers. To make that work it built GVFS, which virtualizes the .git folder and working directory and downloads only the files a developer uses.

On September 10, 2018 Visual Studio Team Services became Azure DevOps, split into five services, and its Git hosting became Azure Repos. Git became the default as TFVC usage declined: in June 2024 Microsoft added a setting to disable creating new TFVC repositories. The current release of the self-hosted Azure DevOps Server became generally available on December 9, 2025.

Why it’s built this way

Offer both centralized and distributed version control
Microsoft had years of TFVC customers when Git took off. Rather than force a switch, it set out to offer the best of both in one product, and kept TFVC working even as it stopped adding features.
Host standard Git rather than a Microsoft variant
Harry acknowledged that Git had a poor reputation in enterprises, but the goal was enterprise features around Git that stayed compatible with every Git client and tool, which the docs still promise.
Scale Git to fit Windows instead of keeping a separate system
Windows was too big for an ordinary clone. Microsoft extended Git and the service with GVFS, which virtualizes the repository so developers fetch only what they touch.
Protect branches with policies, not just permissions
Teams rely on a few branches such as main always being in good shape. Requiring pull requests with reviewers and a clean build of the merged code catches problems before they land, not after.

Timeline

  1. 2006

    Team Foundation Server 2005 ships with centralized version control (March 17)

  2. 2013

    Git hosting added to Team Foundation Service (February)

  3. 2017

    Windows moves to Git on Visual Studio Team Services, using GVFS

  4. 2018

    Visual Studio Team Services becomes Azure DevOps, with Azure Repos (September 10)

  5. 2024

    Setting to disable creating new TFVC repositories (June)

  6. 2025

    Azure DevOps Server reaches general availability (December 9)

Sources12 · facts checked 20 October 2026

Improve this page on GitHub