Git integration Fabric : les 5 actions Source Control

Le point de départ

Git integration dans Microsoft Fabric a l’air simple en surface : on connecte un workspace à un dépôt, on committe, on synchronise. En pratique, le panneau Source Control propose cinq actions dont les noms se ressemblent mais dont le comportement diverge radicalement, et confondre l’une avec l’autre peut littéralement effacer du contenu sans avertissement suffisant.

Cet article documente ce qu’on découvre seulement en testant, pas en lisant la documentation en diagonale.

Deux fournisseurs, deux mécanismes d’authentification

Premier piège classique : Azure DevOps et GitHub ne s’authentifient pas de la même façon, et l’examen (comme la réalité) aime confondre les deux.

Aucun token à gérer côté Azure DevOps : c’est ton identité connectée qui sert de preuve. Côté GitHub, c’est l’inverse : un PAT généré manuellement, aucune notion d’organisation/projet dans l’écran de connexion.

Le prérequis qu’on oublie facilement

Avant même de penser à une branche, deux conditions doivent être réunies au niveau du tenant et de la capacité :

1. Le tenant setting générique de synchronisation Git doit être activé (attention : un réglage spécifique GitHub existe séparément, l’activer seul ne suffit pas pour Azure DevOps, et vice-versa).
2. Le workspace doit être assigné à une vraie capacité Fabric (F-SKU ou Premium). Une licence PPU (Premium Per User), malgré son nom, ne suffit pas : PPU concerne la personne, pas le workspace.

Les tenant settings scindés depuis mi-2025 : un réglage générique, un réglage spécifique par fournisseur, le même schéma se retrouve pour Git integration que pour les Service Principals.

Un piège géographique découvert en le vivant

Sur un tenant récent, une tentative de connexion peut échouer avec un message “This workspace is in a different region”. La cause : quand le workspace Fabric et l’organisation Azure DevOps résident dans des régions différentes, un tenant setting séparé (“Users can export items to Git repositories in other geographical locations”) doit être activé explicitement.

Le réglage tel qu’on le trouve au départ : désactivé pour l’ensemble de l’organisation, dans Admin portal → Tenant settings.

Une fois activé, la bascule ne suffit pas immédiatement. Une notification rappelle que le changement met du temps à se propager :

Après activation, Fabric prévient explicitement que les changements de tenant settings peuvent prendre jusqu’à 15 minutes avant de s’appliquer, un délai facile à oublier quand on retente une connexion immédiatement après et qu’elle échoue encore.

Point notable : cette contrainte ne s’applique qu’à Azure DevOps. GitHub n’est pas concerné par cette restriction géographique.

Les cinq actions du panneau Source Control

C’est le cœur du sujet. Chacune répond à un besoin précis, et les confondre est le piège le plus fréquent.

flowchart LR
    Git[("Dépôt Git<br/>Azure DevOps / GitHub")]
    WS["Workspace Fabric"]
    NewWS["Nouveau workspace"]

    WS -->|"Commit"| Git
    Git -->|"Updates (incrémental)"| WS
    Git -.->|"Switch branch (remplace tout)"| WS
    Git -->|"Branch out to workspace"| NewWS

    style Git fill:#0f3038,stroke:#2ec7c2,color:#eafffb
    style WS fill:#0f3038,stroke:#eafffb,color:#eafffb
    style NewWS fill:#0f3038,stroke:#6ee7d8,color:#eafffb

Le test qui rend ça concret

En pratique : créer un item sur une branche, puis faire Switch branch vers main (où cet item n’existe pas) le fait disparaître immédiatement du workspace, sans confirmation autre qu’un avertissement générique au moment de l’action.

L’avertissement est clair une fois qu’on le lit : “all items in this workspace will be replaced with the items in the target Git branch”, mais il est facile de cliquer vite sans en mesurer la portée la première fois.

À l’inverse, Updates ramène uniquement ce qui a changé côté Git, sans toucher au reste, beaucoup plus sûr pour un usage courant.

Le workflow professionnel complet

Ces actions individuelles prennent tout leur sens une fois assemblées dans un vrai cycle de développement :

1. Branch out to workspace : isoler son travail dans un workspace dédié, connecté à une nouvelle branche
2. Développer et tester dans cet environnement isolé
3. Commit les changements vers la branche de fonctionnalité
4. Pull Request côté fournisseur Git (Azure DevOps ou GitHub) : revue et fusion, pas dans Fabric
5. Une fois mergé, le workspace d’équipe utilise Updates pour récupérer les changements, de façon incrémentale, sans tout écraser

flowchart LR
    A["Branch out to workspace<br/>(nouvelle branche)"] --> B["Développer & tester"]
    B --> C["Commit vers la branche"]
    C --> D["Pull Request<br/>Azure DevOps / GitHub"]
    D --> E["Merge dans main"]
    E --> F["Updates<br/>(workspace d'équipe)"]

Le merge se passe entièrement côté Azure DevOps. Fabric n’intervient qu’après, via Updates, pour synchroniser le workspace.

C’est un vrai pattern GitOps, pas une improvisation propre à Fabric, la nouveauté est dans la façon dont Fabric matérialise chaque étape via son propre panneau Source Control.

Ce que ça implique pour l’industrialisation

Au-delà de la préparation à la certification, ces mécanismes posent les bases d’une vraie stratégie de release management sur Fabric, la discipline qui contrôle comment un changement passe du développement à la production, de façon prévisible :

• Les branches et Pull Requests contrôlent le passage du code au niveau du dépôt
• Les pipelines de déploiement (Dev → Test → Prod) contrôlent le passage du contenu au niveau des workspaces

Ce sont deux portes de contrôle indépendantes mais complémentaires. Un item peut être mergé dans main sans avoir été déployé vers Test ou Prod.

En résumé

Cinq actions, cinq comportements distincts, un seul principe à retenir : est-ce que l’action pousse (Commit), tire de façon incrémentale (Updates), remplace tout (Switch branch), ou crée un nouvel espace séparé (Branch out) ? Une fois ce principe ancré, plus aucune de ces actions n’est surprenante, seulement des outils différents pour des besoins différents.

Sources officielles

• Get started with Git integration : une capacité Fabric (ou Premium) est requise ; connexion Azure DevOps via l’identité Microsoft Entra connectée (« Automatic Git credential »), URL au format https://dev.azure.com/{organization}/{project}/_git/{repository}, authentification OAuth2 ou Service Principal.
• Understand Microsoft Fabric licenses and capacity : « Premium Per User (PPU) doesn’t provision a Fabric capacity » ; il faut une capacité F (ou Trial) pour les items Fabric non-Power BI.
• Git integration tenant settings : « Users can synchronize workspace items with their Git repositories » activé par défaut ; « Users can sync workspace items with GitHub repositories » désactivé par défaut ; « Users can export items to Git repositories in other geographical locations » pour le cas cross-géo (Azure DevOps uniquement, seules les métadonnées sont exportées, non applicable à GitHub).
• Basic concepts in Git integration : les cinq actions Source Control (Commit, Update, Switch branch, Checkout new branch, Branch out) et leurs rôles requis ; Switch branch « overrides all items in the workspace with the content of the selected branch » ; Checkout new branch « doesn’t change the workspace content » ; Update synchronise toute la branche et ne permet pas de choisir les items ; Commit permet de choisir les items ; la restriction cross-géo ne s’applique pas à GitHub ; limites de taille de commit (25 Mo ADO + Service Principal, 125 Mo ADO + SSO, 50 Mo GitHub) ; Azure DevOps non pris en charge si « IP Conditional Access policy validation » est activé.
• Automate git integration with a service principal in Azure DevOps : « Automatic Git credential » vs « Configured credential » (OAuth 2.0 ou Service Principal).
• Fabric CI/CD concepts and best practices : connecteur « Azure DevOps - Source control » (identité Entra, user ou Service Principal) vs connecteur « GitHub - Source control » (PAT : token fine-grained avec permission Contents lecture/écriture, ou token classique avec scope repo).
• About tenant settings : « It can take up to 15 minutes for a setting change to take effect. »