GitAzure DevOps Repos

Azure DevOps Repos

Azure DevOps is Microsoft's end-to-end suite for planning, building, testing, and shipping software. It grew out of Team Foundation Server (TFS) and Visual Studio Team Services, and today it bundles five services that can be used together or independently. For Git users, the most relevant piece is Azure Repos, but it integrates tightly with the rest of the suite — and with the broader Microsoft ecosystem.

The Azure DevOps suite
  • Azure Repos: unlimited private Git repositories (plus legacy TFVC), pull requests, and branch policies.

  • Azure Pipelines: CI/CD that builds, tests, and deploys to any cloud or on-premises, using YAML or a classic visual editor.

  • Azure Boards: Agile planning with work items, backlogs, sprints, Kanban boards, and dashboards.

  • Azure Artifacts: package feeds for npm, NuGet, Maven, Python, and universal packages.

  • Azure Test Plans: manual and exploratory testing tools, test case management, and traceability.

Azure Repos: Git and TFVC

Azure Repos supports two version control systems. Git is the distributed default that almost everyone should choose for new projects. TFVC (Team Foundation Version Control) is a centralized system kept around for legacy migrations — each project can have one TFVC repository, but you can have many Git repositories. Unless you are maintaining an old TFS codebase, use Git.

Aspect

Git

TFVC

Model

Distributed

Centralized

Repos per project

Many

One

Offline work

Full history offline

Requires server connection

Branching

Lightweight, cheap

Path-based, heavier

Recommended for

All new work

Legacy / migration only

Cloning and pushing to an Azure Repos Git repo

Bash
# Clone over HTTPS (uses a Personal Access Token or Git Credential Manager)
git clone https://dev.azure.com/yourorg/yourproject/_git/yourrepo

# Or clone over SSH after adding your public key in User Settings
git clone git@ssh.dev.azure.com:v3/yourorg/yourproject/yourrepo

# Standard workflow
git checkout -b feature/payments
git add .
git commit -m "Add Stripe checkout"
git push -u origin feature/payments
Pull Requests and branch policies

Pull requests in Azure Repos work much like GitHub's, with inline comments, file-by-file review, and required approvals. The standout feature is branch policies — rules attached to a protected branch (often main) that a PR must satisfy before it can merge.

  • Require a minimum number of reviewers: e.g. at least 2 approvals, and optionally reset approvals when new commits are pushed.

  • Check for linked work items: every PR must reference an Azure Boards work item for traceability.

  • Check for comment resolution: all PR comments must be resolved before merge.

  • Build validation: a pipeline must pass before the PR can complete.

  • Automatically include reviewers: add specific people or groups based on the files changed (similar to CODEOWNERS).

  • Limit merge types: allow only squash, rebase, or merge-commit strategies to keep history consistent.

Policies are enforced server-side
Branch policies live on the server, not in a config file in the repo, so they cannot be bypassed by a clever local commit. Only users with the "Bypass policies" permission can override them — keep that permission tightly scoped to a small group of administrators.
Linking commits to work items

Azure Boards and Azure Repos share a tight integration. You link a commit or pull request to a work item by including # followed by the work item ID in the message. The work item then shows the development activity, and the commit links back to the requirement or bug it addresses.

Linking a commit to work item 123

Bash
git commit -m "Fix null reference in checkout flow #123"

# You can reference multiple work items in one commit
git commit -m "Implement coupon codes #456 #457"
Tip
Mentioning `#123` in a pull request title or description creates the same link, and completing the PR can automatically transition the work item to a "Resolved" or "Closed" state if you enable that option — keeping the board in sync with the code without manual updates.
Azure Pipelines YAML

Pipelines are defined in a file named azure-pipelines.yml at the root of your repository. Defining the pipeline as code means it is versioned, reviewed, and branched alongside your application. Here is a typical build-and-test pipeline for a Node.js project:

azure-pipelines.yml

YAML
trigger:
  branches:
    include:
      - main
      - feature/*

pool:
  vmImage: ubuntu-latest

variables:
  nodeVersion: '20.x'

stages:
  - stage: BuildAndTest
    displayName: Build and test
    jobs:
      - job: build
        steps:
          - task: NodeTool@0
            inputs:
              versionSpec: $(nodeVersion)
            displayName: Install Node.js

          - script: npm ci
            displayName: Install dependencies

          - script: npm run lint
            displayName: Lint

          - script: npm test
            displayName: Run tests

          - script: npm run build
            displayName: Build app

  - stage: Deploy
    displayName: Deploy to staging
    dependsOn: BuildAndTest
    condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
    jobs:
      - deployment: deployStaging
        environment: staging
        strategy:
          runOnce:
            deploy:
              steps:
                - script: echo "Deploying with token $(DEPLOY_TOKEN)"
                  displayName: Deploy
Secrets in pipelines
Never hard-code secrets in `azure-pipelines.yml`. Store them as secret pipeline variables or in a variable group backed by Azure Key Vault, then reference them as `$(DEPLOY_TOKEN)`. Secret variables are masked in logs.
The az repos CLI

The Azure CLI ships a devops extension that lets you manage repos, pull requests, and pipelines from the terminal — handy for scripting and CI automation. Install the Azure CLI, add the extension, then sign in.

Setting up and using the az repos CLI

Bash
# Install the Azure CLI (macOS example)
brew install azure-cli

# Add the DevOps extension
az extension add --name azure-devops

# Sign in
az login

# Set defaults so you do not repeat --org / --project every time
az devops configure --defaults \
  organization=https://dev.azure.com/yourorg \
  project=yourproject

# List repositories
az repos list --output table

# Create a new repository
az repos create --name payments-service

# Create a pull request from your current branch into main
az repos pr create \
  --title "Add Stripe checkout" \
  --description "Implements #123" \
  --source-branch feature/payments \
  --target-branch main

# List open pull requests
az repos pr list --status active --output table

# Approve and complete a PR
az repos pr set-vote --id 42 --vote approve
az repos pr update --id 42 --status completed --squash true
Microsoft ecosystem integration
  • Microsoft Entra ID (Azure AD): single sign-on and group-based access control across the whole organization.

  • Visual Studio & VS Code: first-class extensions for browsing repos, creating PRs, and viewing pipeline status inside the editor.

  • Azure cloud: native deploy targets — App Service, AKS, Functions, Container Registry — with managed service connections.

  • Microsoft Teams: notifications for builds, releases, PRs, and work items posted directly into channels.

  • GitHub: Azure Boards and Azure Pipelines both connect to GitHub repositories, so you can keep code on GitHub and planning/CD on Azure DevOps.

Pricing

Azure DevOps is generous at the low end. The first 5 users are free, and they get unlimited private Git repositories, Boards, and Artifacts up to 2 GB. Beyond that you pay per Basic user per month, and Pipelines and Test Plans are billed separately.

Item

Free allowance

Paid

Basic users

First 5 users free

~$6/user/month after

Microsoft-hosted CI/CD

1 free parallel job, 1,800 min/month

~$40/month per extra parallel job

Self-hosted CI/CD

1 free parallel job, unlimited minutes

~$15/month per extra parallel job

Azure Artifacts

2 GB free

~$2/GB/month after

Azure Test Plans

Not free

~$52/user/month

Azure DevOps vs GitHub

Microsoft owns both Azure DevOps and GitHub, which leads to an obvious question: which one should you use? The short answer is that GitHub is Microsoft's strategic, future-facing platform (especially for open source and AI tooling like Copilot), while Azure DevOps remains a mature, enterprise-focused suite with deep Agile planning and flexible pipelines. Many enterprises run both.

Dimension

Azure DevOps

GitHub

Owner

Microsoft

Microsoft

Primary audience

Enterprise teams

Open source + all teams

CI/CD

Azure Pipelines (YAML + classic)

GitHub Actions (YAML)

Planning

Azure Boards (rich Agile)

Issues + Projects

Code review

Pull requests + branch policies

Pull requests + protection rules

Packages

Azure Artifacts

GitHub Packages

AI tooling

Limited

Copilot, Codespaces

Direction

Maintained, stable

Actively expanding

Tip
If you are starting a brand-new project today, GitHub is usually the better default because of its momentum, community, and AI features. Reach for Azure DevOps when you need its mature Boards and Test Plans, or when your organization is already standardized on the Microsoft enterprise stack with Entra ID.