02 · Concevoir et mettre en œuvre une stratégie de contrôle de source

Version : 1.1 · Date : 2026-10-22 · Domaine 2 de l'examen : Design and implement a source control strategy (10 à 15 %)

En une phrase : une bonne stratégie de contrôle de source dit comment l'équipe travaille (branches, pull requests), le garantit par des règles que personne ne contourne sans droit explicite (branch policies, branch protection rules, rulesets, permissions), et garde un dépôt rapide et sain (gros fichiers hors de Git, tags, récupération et purge des données).

Ce que l'examen demande#

Repris mot pour mot du guide d'étude AZ-400 (compétences mesurées au 27 juillet 2026) :

1. Les bases à maîtriser#

Tu connais Git au quotidien : ce chapitre se concentre sur ce que l'examen attend d'un DevOps engineer qui conçoit la stratégie pour une équipe, sur Azure Repos et sur GitHub.

Deux plateformes, une même logique, des noms différents :

2. Concevoir une stratégie de branches#

2.1 Les trois modèles de l'examen#

La recommandation de Microsoft tient en trois règles (Adopt a Git branching strategy) :

1. Feature branches pour tout nouveau développement et tout correctif ;
2. fusion dans main uniquement par pull request ;
3. un main toujours de qualité et à jour (build propre, tests au vert).

2.2 Release Flow, le modèle de Microsoft#

Microsoft (équipe Azure DevOps) applique le Release Flow : les correctifs sont faits d'abord dans main, puis portés vers la release branch par cherry-pick. On préfère le cherry-pick au merge pour contrôler exactement les commits portés (un merge de la release dans main ramènerait des changements propres à la release).

gitGraph
    commit id: "A"
    branch feature/login
    commit id: "B"
    checkout main
    merge feature/login id: "PR 1"
    branch release/20
    commit id: "stabilisation"
    checkout main
    commit id: "fix bug (PR 2)"
    checkout release/20
    cherry-pick id: "fix bug (PR 2)"

Quand une version n'est plus supportée : verrouiller sa release branch (Lock dans Azure Repos, Lock branch sur GitHub).

2.3 Nommer et organiser les branches#

Conventions suggérées par Microsoft : users/{alias}/{description}, feature/{nom}, bugfix/{description}, hotfix/{description}, release/{numéro}. Dans Azure Repos, on peut imposer des dossiers de branches (Require branch folders) par les permissions : retirer Create branch au niveau du dépôt et l'accorder seulement sur feature/*, users/*… Les branches en / s'affichent en arbre dans le portail.

Pourquoi pas des tags pour les releases ? Microsoft déconseille de gérer les releases uniquement par tags : un tag se pousse à part (git push --tags oublié), et on ne peut pas y appliquer de correctif. Les tags restent utiles pour marquer les versions livrées (voir section 8).

3. Le workflow de pull request : branch policies et branch protection rules#

3.1 Azure Repos : les branch policies#

Dès qu'une policy est active sur une branche, Azure Repos applique automatiquement deux règles : les mises à jour de la branche passent par une PR, et la branche ne peut plus être supprimée. Les policies s'appliquent selon la branche cible de la PR : ne pas en mettre sur des branches temporaires (leur suppression automatique échouerait).

Microsoft recommande deux relecteurs pour une PR importante, et ne pas laisser l'auteur s'auto-approuver sur main.

En CLI (extension azure-devops), exemples issus de Microsoft Learn :

# 2 approbations, l'auteur ne compte pas, votes remis à zéro au push
az repos policy approver-count create \
  --blocking true --enabled true --branch main --repository-id <repo-id> \
  --minimum-approver-count 2 --creator-vote-counts false --reset-on-source-push true \
  --allow-downvotes false

# Relecture obligatoire de l'équipe sécurité sur l'infra et les pipelines
az repos policy required-reviewer create \
  --blocking true --enabled true --branch main --repository-id <repo-id> \
  --message "Security review required for protected paths." \
  --path-filter "/infra/*;/pipelines/*" --required-reviewer-ids <email-ou-groupe>

# Build validation : le pipeline CI doit passer sur chaque PR vers main
az repos policy build create \
  --blocking true --enabled true --branch main --repository-id <repo-id> \
  --build-definition-id <id-pipeline> --display-name "CI PR" \
  --manual-queue-only false --queue-on-source-update-only true --valid-duration 720

# Commentaires résolus obligatoires
az repos policy comment-required create --blocking true --enabled true --branch main --repository-id <repo-id>

--branch-match-type prefix applique la policy à tout un dossier (par exemple release/).

3.2 GitHub : branch protection rules et rulesets#

Branch protection rule (une seule par branche, motif fnmatch comme release/*) :

Rulesets (plans Team et Enterprise ; rulesets d'organisation multi-dépôts avec Enterprise) : une liste nommée de règles pour des branches, des tags ou des pushs. Différences clés avec les branch protection rules :

# GitHub CLI : lister les rulesets du dépôt et voir lesquels s'appliquent à une branche
gh ruleset list
gh ruleset check main

3.3 CODEOWNERS#

Le fichier CODEOWNERS désigne les propriétaires de chemins ; ils sont demandés automatiquement en revue, et deviennent obligatoires avec Require review from Code Owners.

# .github/CODEOWNERS : la dernière règle qui correspond l'emporte
*                       @fabrikam/platform
/infra/                 @fabrikam/cloud-ops
/pipelines/             @fabrikam/cloud-ops @fabrikam/security
/.github/CODEOWNERS     @fabrikam/security

À retenir : emplacements cherchés dans l'ordre .github/, racine, docs/ (le premier trouvé gagne) ; le fichier doit être sur la branche de base de la PR ; les propriétaires doivent avoir un accès write explicite ; une seule approbation d'un des propriétaires suffit ; protéger le fichier lui-même en lui donnant un propriétaire.

Équivalent Azure Repos : la policy Automatically included reviewers avec des filtres de chemin.

4. Restreindre les merges#

4.1 Les merge types d'Azure Repos#

# main : seulement squash (historique propre pour des branches courtes)
az repos policy merge-strategy create --blocking true --enabled true --branch main --repository-id <repo-id> \
  --allow-squash true --allow-no-fast-forward false --allow-rebase false --allow-rebase-merge false

Microsoft rappelle que Limit merge types est un réglage de gouvernance de l'historique, pas un contrôle de sécurité : si l'audit exige la séquence exacte des commits, préférer le merge commit au squash. Le rebase à la complétion de la PR est impossible si la branche source a elle-même des policies.

Sur GitHub : dans les paramètres du dépôt, autoriser ou non merge commits, squash merging, rebase merging ; et Require linear history dans la règle de protection.

4.2 Empêcher les contournements#

Les deux permissions de bypass d'Azure Repos ont remplacé l'ancienne Exempt from policy enforcement. Microsoft insiste : les réserver à un très petit nombre d'administrateurs ou à une procédure d'urgence documentée.

5. Gérer les gros fichiers : Git LFS, git-fat, Azure Artifacts#

5.1 Ce qui va où#

Limites Azure Repos à connaître : fichier ≤ 100 Mo conseillé, dépôt < 10 Go conseillé (250 Go maximum), push ≤ 5 Go (les objets LFS ne comptent pas dans cette limite). La policy de dépôt Maximum file size bloque à la source tout push qui contient un fichier trop gros ; d'autres policies de dépôt existent (File path validation, Commit author email validation, Reserved names, Maximum path length, Case enforcement).

5.2 Git LFS#

Git LFS stocke dans le dépôt un pointeur de quelques lignes et met le contenu réel dans un stockage séparé ; le bon contenu est téléchargé au clone ou au changement de branche. Azure Repos le prend en charge gratuitement.

git lfs install                              # une fois par poste
git lfs track "*.psd" "*.mp4"                # écrit les règles dans .gitattributes
git add .gitattributes                       # à committer AVANT les fichiers suivis
git add design/maquette.psd && git commit -m "add mockup"
git lfs migrate import --include="*.zip"     # convertir l'historique existant (réécrit les commits)

# Pipeline Azure : télécharger les fichiers LFS au checkout
steps:
- checkout: self
  lfs: true

Limites à connaître : chaque poste doit avoir le client LFS (sinon on récupère les pointeurs) ; Git ne fusionne pas deux versions d'un binaire (coordination, file locking LFS) ; pas de SSH sur Azure Repos pour un dépôt avec LFS ; glisser un binaire dans l'interface web commit le binaire, pas le pointeur ; agent auto-hébergé : installer git-lfs.

5.3 git-fat#

git-fat (projet open source, hors documentation Microsoft hormis le guide d'étude) suit la même idée que LFS : un filtre Git (filter=fat dans .gitattributes) remplace les gros fichiers par un marqueur, et le contenu est synchronisé par rsync vers un serveur que vous hébergez (fichier .gitfat). Commandes : git fat init, git fat push, git fat pull. Il ne dépend que de Python et rsync.

6. Passer à l'échelle : Scalar, clones partiels, cross-repository sharing#

6.1 Pourquoi un dépôt devient lent#

Deux causes : un long historique et des gros binaires. S'y ajoutent les dossiers très plats (des centaines d'entrées dans un même dossier) et les branches inutilisées (chaque clone télécharge les objets de toutes les branches distantes). Le panneau Health and usage d'Azure Repos et les outils git-sizer ou git survey mesurent ces facteurs.

Piège : le stockage Azure Repos est append-only. Supprimer une branche ou forcer un push ne réduit pas un dépôt déjà gros ; seule la recréation du dépôt avec le contenu utile libère la place.

6.2 Scalar et les clones partiels#

Scalar (Microsoft, intégré à Git) accélère les très gros dépôts en activant des fonctions avancées de Git :

scalar clone https://dev.azure.com/fabrikam/Plateforme/_git/monorepo   # clone optimisé
git clone --depth 1 <url>                    # shallow clone : historique limité (idéal en CI)
git clone --filter=blob:none <url>           # partial clone : historique complet, contenus à la demande
git sparse-checkout set services/api infra   # ne garder que ces dossiers

En pipeline Azure, le paramètre fetchDepth du checkout limite la profondeur de fetch. Microsoft cite aussi VFS for Git (protocole GVFS d'Azure Repos), l'ancêtre de Scalar pour Windows et Office.

6.3 Monorepo, multirepo et partage entre dépôts#

Cross-repository sharing : partager du code commun entre dépôts par des packages versionnés (le plus robuste), des Git submodules (fichier .gitmodules, pointeur vers un commit d'un autre dépôt) ou des outils comme git-subrepo.

7. Les permissions du dépôt#

7.1 Azure Repos#

Trois niveaux, avec héritage : Git repositories (tous les dépôts du projet) → un dépôt (héritage désactivable) → une branche (sous-ensemble des permissions).

Le créateur d'une branche reçoit sur celle-ci Contribute, Force push, Manage permissions et Remove others' locks (pour pouvoir supprimer sa branche après la PR). Depuis 2023, il ne reçoit plus Edit policies automatiquement. Sur une branche commune comme main, revoir ces droits.

Modèle recommandé par Microsoft pour main : Contributors contribuent par PR sans bypass ; Project Administrators ont Edit policies et Manage permissions ; les droits de bypass seulement pour des responsables d'urgence si la procédure l'exige.

7.2 GitHub#

S'y ajoutent les base permissions de l'organisation (droit minimal de tous les membres, hors collaborateurs externes), les teams, les rôles personnalisés (Enterprise) et des rôles d'organisation comme Security manager (lecture de tous les dépôts). Un accès plus élevé sur un dépôt l'emporte sur la base permission.

8. Les tags#

git tag -a v2.3.0 9fceb02 -m "Release 2.3.0"   # tagger un commit précis
git push origin v2.3.0                         # un tag se pousse à part !
git push origin --tags                         # ou tous les tags
git tag -d v2.3.0 && git push origin --delete v2.3.0   # supprimer (Force push requis sur Azure Repos)

Points d'examen :

• Azure Repos : le portail (vues Tags et Commits) ne crée que des tags annotés ; les tags lightweight se créent en ligne de commande ; il faut la permission Create tag (Contributors) ; supprimer un tag demande Force push.
• Nommage : suivre le versionnement sémantique avec un v (v1.0.0, v0.2.0-alpha, v5.9-beta.3) ; noms en minuscules séparés par des tirets ; pas d'espaces ni de ~ ou : ; pas de nom de 40 caractères hexadécimaux (confusion avec un SHA).
• GitHub : un tag peut porter une release (notes, binaires) ; les rulesets ciblent aussi les tags (qui peut créer, supprimer, renommer).
• Garder un nombre raisonnable de tags : ils sont transférés à chaque fetch (quelques dizaines de milliers au plus).
• Versionnement des packages et artefacts : chapitre 03.

9. Récupérer des données avec Git#

Tant qu'un objet existe dans le dépôt local ou distant, on peut le retrouver.

flowchart TD
    A["Donnée perdue"] --> B{"Déjà poussée sur le serveur ?"}
    B -- "Oui, branche supprimée sur Azure Repos" --> C["Portail : Branches, nom exact,<br/>Restore branch"]
    B -- "Non, perdue en local" --> D["git reflog : retrouver le SHA"]
    D --> E["git branch recup SHA"]
    B -- "Un fichier seulement" --> F["git checkout SHA^ -- fichier"]
    C --> G["Policies et permissions à recréer"]

Côté Azure Repos, une branche supprimée se restaure depuis le portail : vue Branches, rechercher le nom exact, lien Search for exact match in deleted branches, puis Restore branch. Il n'y a pas de rétention sur les branches supprimées, mais les policies et permissions ne sont pas restaurées. Un dépôt supprimé passe par la corbeille (recycle bin, API REST).

10. Supprimer des données du contrôle de source#

Trois raisons : réduire la taille, retirer un gros fichier ajouté par erreur, retirer un fichier sensible (mot de passe, clé).

10.1 La démarche pour un secret#

1. Révoquer et renouveler le secret immédiatement : dès qu'il est poussé, il doit être considéré comme compromis ; le nettoyage de l'historique ne suffit jamais.
2. Geler le dépôt (prévenir l'équipe, éventuellement Lock la branche) pour ne pas perdre de pushs pendant l'opération.
3. Réécrire l'historique :
   • git filter-repo : l'outil recommandé pour réécrire l'historique (remplace git filter-branch) ;
   • BFG Repo-Cleaner : plus simple pour un cas courant.
4. Force push (permission Force push sur Azure Repos), puis chaque développeur re-clone ou rebase.
5. Prévenir la récidive : .gitignore, secret scanning push protection de GitHub Advanced Security (chapitre 07), policy Maximum file size, Key Vault pour les secrets.

# git filter-repo : retirer un fichier de tout l'historique
git filter-repo --invert-paths --path config/secrets.json

# BFG : supprimer un fichier, ou remplacer des valeurs listées dans un fichier
bfg --delete-files secrets.json
bfg --replace-text passwords.txt

git push --force --all && git push --force --tags

Si le secret est dans le dernier commit non poussé : git commit --amend. S'il est plus ancien mais non poussé : rebase interactif (git rebase -i <commit>~1, edit, corriger, git commit --amend, git rebase --continue).

10.2 Les limites d'Azure Repos#

• Le stockage est append-only : un commit retiré de l'historique reste accessible par son SHA (et via les anciennes PR) ; l'espace n'est pas récupéré ; Azure Repos ne permet pas de supprimer un commit précis.
• La seule façon d'effacer réellement : recréer le dépôt avec le contenu nettoyé (git push --mirror vers un nouveau dépôt), reconfigurer policies, permissions et pipelines, puis supprimer l'ancien.

11. Labs conseillés#

Dans une organisation Azure DevOps et un compte GitHub de test (gratuits pour ces labs).

1. Protéger main dans Azure Repos
   • Créer un dépôt, puis ajouter en CLI : 2 relecteurs avec reset au push, build validation sur un pipeline YAML simple, commentaires résolus, merge type squash seulement.
   • Pousser directement sur main, puis ouvrir une PR.
   • Résultat attendu : le push direct est refusé ; la PR reste bloquée tant qu'il manque une approbation ou que le build échoue.
2. Reproduire la même protection sur GitHub
   • Créer un ruleset sur main : PR obligatoire, 1 approbation, dismiss stale, linear history ; ajouter un CODEOWNERS sur /infra/ et activer Require review from Code Owners.
   • Modifier un fichier sous /infra/ dans une PR.
   • Résultat attendu : le code owner est demandé automatiquement et son approbation est exigée.
3. Git LFS
   • git lfs install, git lfs track "*.bin", committer .gitattributes, puis un fichier de 50 Mo ; cloner ailleurs avec et sans client LFS ; ajouter lfs: true dans le checkout d'un pipeline.
   • Résultat attendu : sans client LFS on obtient un pointeur texte ; avec, le vrai fichier ; le pipeline récupère le binaire.
4. Récupération
   • Supprimer une branche poussée, la restaurer depuis le portail Azure Repos ; en local, git reset --hard HEAD~3 puis retrouver les commits par git reflog.
   • Résultat attendu : la branche revient sans ses policies ; les commits sont récupérés dans une nouvelle branche.
5. Purge d'un faux secret
   • Committer et pousser un fichier secrets.txt contenant une fausse valeur ; le retirer avec git filter-repo, force push ; tenter d'ouvrir l'ancien commit par son SHA dans Azure Repos.
   • Résultat attendu : le fichier disparaît des branches, mais l'ancien commit reste consultable par son SHA (append-only).

Nettoyage : supprimer les dépôts de test (corbeille Azure Repos, Delete repository sur GitHub).

12. Pièges d'examen#

13. Scénarios corrigés#

1. Une équipe de 6 développeurs déploie en production plusieurs fois par jour avec une bonne couverture de tests. Elle veut le moins de conflits de merge possible. Quelle stratégie de branches ?

Trunk-based development : branches très courtes intégrées souvent dans main, travail inachevé derrière des feature flags. Les release branches seraient inutiles (une seule version en production).

2. Un éditeur maintient les versions 3.x et 4.x en parallèle et doit livrer des correctifs de sécurité sur les deux. Que mettre en place ?

Des release branches (release/3, release/4) en plus des feature branches. Corriger dans main puis cherry-pick vers chaque release branch (Release Flow) ; verrouiller une release branch en fin de support.

3. Sur Azure Repos, tout changement de /pipelines doit être approuvé par l'équipe plateforme, et toute PR vers main doit avoir 2 approbations, sans que l'auteur compte. Quelles policies ?

Require a minimum number of reviewers à 2, Allow requestors to approve their own changes désactivé (--creator-vote-counts false) ; Automatically included reviewers Required avec le filtre /pipelines/* et l'équipe plateforme.

4. Un développeur obtient l'approbation, puis pousse un nouveau commit qui modifie la logique, et complète la PR. Comment l'empêcher ?

Dans la policy de relecteurs, Reset all approval votes (ou Require at least one approval on the last iteration) quand de nouveaux changements sont poussés ; sur GitHub, Dismiss stale pull request approvals et Require approval of the most recent reviewable push.

5. L'organisation GitHub veut appliquer à tous ses dépôts la règle « pas de force push sur main » et, sur certains dépôts, une règle plus stricte en plus. Quelle fonctionnalité ?

Des rulesets : un ruleset d'organisation (GitHub Enterprise) plus des rulesets de dépôt ; ils se cumulent, la version la plus restrictive s'applique. Une branch protection rule ne peut pas se cumuler.

6. Une équipe de jeu vidéo versionne des textures de 200 Mo modifiées chaque jour ; les clones prennent une heure. Que recommander ?

Git LFS pour ces fichiers (git lfs track, .gitattributes committé d'abord, git lfs migrate import pour l'historique) ; client LFS sur tous les postes et lfs: true dans les pipelines ; en HTTPS (pas de SSH avec LFS sur Azure Repos).

7. Un monorepo de plusieurs dizaines de Go : les développeurs ne travaillent que sur 2 ou 3 dossiers. Que proposer ?

Scalar (scalar clone) qui active partial clone, sparse-checkout, background prefetch, commit-graph et file system monitor ; git sparse-checkout set pour les dossiers utiles ; shallow fetch en CI.

8. Une branche feature/paiement a été supprimée par erreur sur Azure Repos il y a 6 mois. Peut-on la récupérer ?

Oui : vue Branches, rechercher le nom exact, Search for exact match in deleted branches, puis Restore branch (pas de rétention sur les branches supprimées). Les policies et permissions de la branche sont à reconfigurer.

9. Une clé de stockage a été poussée dans main hier. Quelle est la première action ?

Révoquer / régénérer la clé du compte de stockage (et la ranger dans Key Vault). Ensuite seulement : réécrire l'historique avec git filter-repo ou BFG, force push, re-clone par l'équipe. Sur Azure Repos, l'ancien commit reste lisible par son SHA : si cela pose problème, recréer le dépôt.

10. Des Contributors ont pu supprimer des tags de release. Pourquoi, et comment l'éviter ?

Supprimer un tag demande Force push : vérifier qu'aucun Contributor n'a cette permission (accordée par exemple au créateur d'une branche, ou par une assignation directe) ; sur GitHub, un ruleset de tags qui interdit la suppression.

14. Pour aller plus loin#

• Git hooks (pre-commit, commit-msg…) pour contrôler en local avant le push (formatage, détection de secrets) ; ils ne remplacent pas les contrôles serveur, puisque chacun peut les désactiver.
• Inner source et forks : forks dans Azure Repos et GitHub pour contribuer à un dépôt sans droit d'écriture, avec PR depuis le fork.
• Commits signés (GPG, SSH ou S/MIME) et Require signed commits : prouver l'auteur réel d'un commit.
• Merge queue GitHub : teste chaque PR sur la dernière version de main avant de fusionner, utile quand beaucoup de PR arrivent en même temps.
• Migration Azure Repos vers GitHub (Enterprise Live Migrations) : les branch policies deviennent des rulesets ; les relecteurs par chemin doivent être recréés à la main en CODEOWNERS.
• Policies de dépôt d'Azure Repos (File path validation, Commit author email validation, Reserved names) pour bloquer à l'entrée ce qui n'a rien à faire dans le dépôt.

15. Fiche à retenir#

• Microsoft recommande feature branches + PR + main toujours sain ; release branches seulement pour plusieurs versions.
• Release Flow : corriger dans main, puis cherry-pick vers release/* ; verrouiller en fin de support.
• Azure Repos : une policy suffit pour rendre la PR obligatoire et interdire la suppression de la branche.
• Policies : minimum reviewers, linked work items, comment resolution, limit merge types, build validation, status checks, automatically included reviewers.
• GitHub : branch protection rule (une par branche) ou rulesets (cumulables, la plus restrictive gagne, bypass list).
• CODEOWNERS : .github/, racine, docs/ ; dernière règle qui correspond ; propriétaires en write.
• Merge types Azure Repos : basic (no-ff), squash, rebase + fast-forward, rebase + merge commit (semi-linéaire).
• Bypass policies (PR, push) et Force push : aucun groupe par défaut, à réserver à très peu de personnes.
• Gros binaires changeant souvent → Git LFS (gratuit, pas de SSH) ; serveur maison → git-fat (rsync) ; dépendances → Artifacts.
• Limites Azure Repos : fichier 100 Mo, dépôt < 10 Go conseillé (250 Go max), push 5 Go ; policy Maximum file size.
• Gros dépôts : Scalar (partial clone, sparse-checkout, prefetch), shallow fetch en CI.
• Tags : annotés au portail, lightweight en CLI ; git push origin <tag> ; supprimer = Force push.
• Récupérer : git reflog, git fsck --lost-found, git checkout <sha>^ -- fichier, Restore branch au portail.
• Secret poussé : révoquer d'abord, puis git filter-repo ou BFG, force push, re-clone.
• Azure Repos est append-only : la vraie suppression passe par la recréation du dépôt.

Références#

Toutes lues le 21/10/2026 (Microsoft Learn sauf mention) :

• Study guide for Exam AZ-400
• Adopt a Git branching strategy
• About branches and branch policies
• Set and manage branch policies
• Set Git repository settings and policies
• Secure repositories and pull requests
• az repos policy merge-strategy
• Set Git repository permissions
• Set branch permissions
• Default Git repository and branch permissions
• Lock a branch
• Work with large files in your Git repo
• Git limits
• Optimize repository performance
• Repository health
• Pipeline options for Git repositories
• Use Git tags
• Restore a deleted Git branch from the web portal
• Remove a large binary from your Git history
• Set up secret scanning (push protection)
• Training : Manage and configure repositories (unités Scalar, recover, purge, permissions GitHub, tags GitHub)
• Repository Scalability Improved (release notes sprint 273)
• Complete post-migration tasks (Enterprise Live Migrations)
• GitHub Docs : About rulesets, About protected branches, About code owners
• git-fat (GitHub, jedbrown/git-fat) · git-filter-repo · BFG Repo-Cleaner