Azure Repo

À la fin de ce tutoriel, vous saurez créer un dépôt Azure Repos, importer un dépôt GitHub, relier Visual Studio, et manier les dix concepts (repository, branche, politiques, clone, pull, push, commit, fork, notifications, projets, équipes) — corps text-first, sans images externes, sans secrets en clair.

Niveau : Débutant · Temps estimé : 40–55 min · Versions testées : Azure DevOps Services (portail 2026), Git 2.x, Visual Studio 2022 · Dernière vérification : 2026-09-12

Slug : azure-repo · Série : Azure DevOps (Lesson 16 / 31) · WP #1040 · Focus SEO : azure repos / azure repo

Prérequis

• Organisation et projet lab — Azure Projects, organisation et configuration
• Compte Microsoft ou Entra ID + MFA ; droits Contribute (Code) sur le projet
• Notions Git de base : Git — contrôle de version distribué
• Optionnel : Visual Studio 2022 (workload ASP.NET) ; Git for Windows ; Azure CLI + extension azure-devops
• Pour la suite CI : Azure DevOps Tools, pipeline CI/CD

Coût estimé : 0 € (repos Git privés illimités sur le Free tier Azure DevOps Services). Région lab Azure éventuelle : canadacentral. Aucun PAT en clair dans Git.

Ce que nous allons construire

Projet Azure DevOps (lab)
  └── Azure Repos
        ├── Dépôt vide MyAppRepo (clone URL)
        ├── Import GitHub (URL + nom)
        ├── Concepts : Git vs TFVC, branches, policies, fork
        ├── Visual Studio : remotes, pull / push / commit
        └── Suite : PR → Pipelines / Jenkins

(Schéma local Excalidraw / draw.io, alt : « Azure Repos : dépôt vide, import GitHub, clone Visual Studio ». Corps text-first — tableaux et étapes, sans balise img.)

Ce guide enrichit le post WordPress #1040 (azure-repo) : on conserve toute la leçon d’origine (définition, Git / TFVC, dix concepts, import GitHub, dépôt vide, Visual Studio), puis on développe le vocabulaire 2026, les pièges et le maillage.

Étape 1 — Azure Repos, c’est quoi ?

Azure Repos (souvent dit Azure Repository ou Azure Repo) est l’ensemble d’outils de contrôle de version pour gérer le code dans Azure DevOps. Si vous débutez : le contrôle de version permet de suivre chaque modification du code dans le temps. Beaucoup de logiciels existent pour cela. Un système de contrôle de version permet de tracer le changement de chaque développeur, de fusionner en sécurité, de tester, puis de publier en production.

Dans le portail : projet → Repos. C’est le service Code de l’ancien VSTS, aujourd’hui nommé Azure Repos (voir le tableau VSTS → Azure DevOps dans Azure DevOps Tools). Un projet peut héberger plusieurs dépôts ; chaque dépôt peut avoir plusieurs branches.

Azure Repos n’est pas Azure Boards (suivi du travail) ni Azure Pipelines (CI/CD). Le dépôt est la source de vérité ; Boards lie les work items aux commits ; Pipelines (ou Jenkins avec Azure Repos) construit après un push.

Étape 2 — Deux types de contrôle de version (conservé)

Il existe deux types de contrôle de version dans Azure Repos. Conservez les deux ; en 2026 le lab utilise Git.

Git : chaque machine a une copie complète de l’historique. Travail hors ligne, branches feature/…, revue via pull request. TFVC : le serveur est la référence ; le client extrait souvent un sous-ensemble. Microsoft pousse Git pour le cloud ; TFVC reste pour les dépôts historiques.

Si le projet a été créé avec Git (défaut New project), le menu Repos montre Files, Commits, Pushes, Branches, Tags, Pull requests. Un projet TFVC affiche plutôt Source Control Explorer. Ne mélangez pas les deux modèles dans le même dépôt.

Étape 3 — Dix concepts Azure Repos (conservés et enrichis)

Voici les dix concepts de la leçon d’origine, conservés mot pour mot sur le fond, précisés pour le portail 2026.

1. Repository (dépôt). Emplacement du code géré par le contrôle de version. Azure Repos prend en charge Git et TFVC. Vous pouvez créer plusieurs dépôts dans un seul projet et plusieurs branches par dépôt. Le premier dépôt porte souvent le nom du projet ; New repository en ajoute d’autres (docs, infra, front).
2. Branch (branche). Référence légère qui conserve l’historique des commits et isole une fonctionnalité ou un correctif par rapport à master / main et au reste du travail. En Git, créer une branche est quasi instantané. Convention lab : feature/<id>-sujet ou fix/<id>-sujet.
3. Branch policies (politiques de branche). Pièce essentielle du flux Git. Elles protègent les branches critiques (main, parfois master) : revue minimale, work item lié, build vert, types de merge limités. Un git push direct sur main peut alors être refusé.
4. Pull et Clone. Clone : copie locale complète d’un dépôt Git existant (historique + branches distantes connues). Pull : met à jour le dépôt local avec le distant (git pull = fetch + merge ou rebase selon config).
5. Push et Commit. Un commit est un groupe de changements enregistré dans le dépôt local. Le push envoie ces commits vers le dépôt distant. Sans push, l’équipe ne voit rien. Message utile : verbe + #ID de work item Boards.
6. Fork. Copie complète d’un dépôt, y compris tous les commits de fichiers et, en option, les branches. Utile pour contribuer à un dépôt où vous n’avez pas le droit de pousser : vous forkez, vous travaillez, vous ouvrez une pull request vers l’original.
7. Git. Système de contrôle de version distribué. La copie locale est un dépôt complet : travail hors ligne ou à distance, puis synchronisation. C’est le modèle par défaut Azure Repos en 2026.
8. Notification. E-mail (ou webhook) lorsqu’un work item, une revue, une pull request, un fichier source ou un build change. Réglez le niveau (projet / équipe / perso) pour éviter le bruit.
9. Projects (projets). Un projet est l’espace où un groupe planifie, suit l’avancement et collabore pour construire une solution. Il contient Repos, Boards, Pipelines, Artifacts. Voir Azure Projects.
10. Teams (équipes). Une équipe est un sous-ensemble des membres du projet. Elle permet de catégoriser le travail (backlogs, sprints, notifications). Un grand projet a souvent plusieurs équipes, un seul dépôt Git partagé.

Ces dix notions se retrouvent dans Repos, Project settings et User settings. Gardez-les comme carte mentale avant d’importer ou de cloner.

Étape 4 — Importer un dépôt depuis GitHub (lab conservé)

Pour importer un dépôt déjà créé sur GitHub (leçon d’origine, trois étapes) :

1. Dans le projet Azure DevOps, ouvrez Repos. Dans le menu déroulant Repos, cliquez sur Import repository.
2. Indiquez l’URL du dépôt GitHub. S’il est privé, fournissez les identifiants (PAT GitHub à scope minimal, jamais collé dans le README). Donnez un Name au dépôt Azure Repos (ex. MyAppRepo).
3. Cliquez sur Import. Après quelques minutes, le dépôt apparaît dans la liste Azure Repos (Files / Commits).

Limites utiles : l’import copie l’historique Git (commits, branches selon options). Les issues GitHub, les Actions et les wikis ne deviennent pas automatiquement des work items Boards. Après import : vérifiez la branche par défaut (main plutôt que master si vous le pouvez), ajoutez un .gitignore, et ne commitez aucun secret.

Alternative 2026 : New repository vide + git remote add + git push --all depuis un clone GitHub local, si l’assistant d’import est indisponible.

Étape 5 — Créer un dépôt Azure Repos vide (lab conservé)

Pour un dépôt vide (leçon d’origine) :

1. Ouvrez Azure Repos, puis New Repository dans le menu déroulant.
2. Donnez un nom (exemple d’origine : MyAppRepo) et cliquez sur Create. Laissez le type Git (pas TFVC).
3. Une fois créé, le portail affiche l’URL de clone et les étapes pour pousser un dépôt existant (git remote add origin … puis git push -u origin main).

Cochez Add a README si vous voulez un premier commit sur main (clone plus simple). Décochez si vous allez pousser un historique local déjà initialisé — évite le rejet « unrelated histories ».

URL typique :

https://dev.azure.com/<organisation>/<projet>/_git/MyAppRepo

Remplacez <organisation> et <projet>. SSH : git@ssh.dev.azure.com:v3/<org>/<projet>/MyAppRepo après enregistrement de la clé publique.

Étape 6 — Visual Studio : projet et dépôt Azure (lab conservé)

La leçon d’origine relie Visual Studio à Azure Repos. Les cinq étapes sont conservées :

1. Créez un nouveau projet Visual Studio : application ASP.NET Core avec du code d’exemple.
2. Menu Git → Manage Remotes.
3. Cliquez sur Add : nommez le remote (souvent origin) et, dans la zone Fetch, collez l’URL du dépôt Azure Repos (celle de l’étape 5).
4. Ensuite, le menu Git sert aux opérations pull, push, commit, fetch, branches.
5. Après le premier push réussi, les fichiers du projet apparaissent dans Azure Repos → Files.

Auth : Git Credential Manager (navigateur + MFA) plutôt qu’un PAT collé dans l’URL. En VS Code : Remote, puis Source Control. Même URL, mêmes commandes git.

Vérification : Repos → Commits doit montrer votre commit ; Pushes l’envoi. Si Files reste vide, le remote pointe vers un autre dépôt ou le push a échoué (scope, MFA, mauvaise org).

Étape 7 — Clone, branche, pull request (enrichissement)

Après le dépôt vide ou l’import, le flux quotidien Git sur Azure Repos :

main (protégé par policies)
  └── feature/<id>-sujet
        ├── commits locaux + #ID Boards
        ├── git push -u origin
        ├── pull request + revue
        └── merge (squash) → delete branch

1. git clone l’URL HTTPS ou SSH, puis git checkout main et git pull.
2. git checkout -b feature/42-notes — isolez le travail (concept Branch).
3. Commit : git commit -m "docs: notes lab Azure Repos #42" (concept Commit + lien Boards).
4. git push -u origin feature/42-notes (concept Push).
5. Create a pull request : source feature/… → cible main, reviewers, work items.
6. Branch policies sur main : au moins un reviewer ; plus tard, build pipeline obligatoire.

az repos pr create et az repos policy list existent si l’extension CLI est installée — sans PAT dans la ligne de commande. Suite naturelle : YAML CI, agents Microsoft-hosted ou self-hosted.

Erreurs fréquentes

Quiz (3 questions)

1. Quels sont les deux types de contrôle de version dans Azure Repos ? – A. Boards et Pipelines – B. Git (distribué) et TFVC (centralisé) – C. Fork et Notification uniquement

2. Après Import repository, que devez-vous fournir ? – A. Un ARM template obligatoire – B. L’URL GitHub (identifiants si privé) et le Name du dépôt Azure – C. Un agent self-hosted déjà allumé

3. Dans Visual Studio, où colle-t-on l’URL Azure Repos ? – A. NuGet Package Manager – B. Git → Manage Remotes → Add / Fetch – C. Team Explorer « Work Items » seulement

Réponses : 1‑B · 2‑B · 3‑B

FAQ rapide

• Azure Repo = Azure Repos ? Oui — Azure Repo est le slug / titre menu ; le produit s’appelle Azure Repos.
• Faut-il TFVC pour un lab 2026 ? Non — créez un dépôt Git.
• GitHub à la place ? Possible : import, ou Pipelines / Jenkins branchés sur GitHub. Azure Repos reste l’option native.
• Où va le CI ensuite ? Azure Pipeline ou Jenkins with Azure Repos.

Pour aller plus loin

• Doc : Azure Repos Git, Import a repo, Branch policies
• CLI : az repos

Maillage série Azure DevOps

Retour parcours Azure DevOps — hub de la série et leçons sœurs.