Git Integration in Microsoft Fabric
Version control your Microsoft Fabric artifacts with Git integration. Manage notebooks, pipelines, and semantic models with Azure DevOps and GitHub.
Git integration in Microsoft Fabric brings professional software development practices to the analytics lifecycle, enabling version control, branching, code review, and automated deployment for lakehouses, warehouses, notebooks, semantic models, and reports. Before Git integration, Fabric workspace changes were immediate and irreversible — one developer's accidental deletion could destroy hours of work with no recovery path. Our enterprise deployment team implements Git-based development workflows for organizations adopting Microsoft Fabric across their analytics estate.
This guide covers setup, branching strategies, workspace synchronization, CI/CD integration, and production governance patterns for Fabric Git integration in 2026.
What Fabric Git Integration Provides
Fabric Git integration connects a workspace to an Azure DevOps or GitHub repository, synchronizing workspace items as text-based definitions stored in Git.
Supported item types:
| Fabric Item | Git Support | Format in Git | Notes |
|---|---|---|---|
| Semantic models | Full | TMDL (folder structure) | Measures, tables, relationships as individual files |
| Reports | Full | PBIR (JSON) | Pages, visuals, bookmarks as text |
| Notebooks | Full | .py / .ipynb | Code cells and markdown |
| Lakehouses | Metadata only | JSON definition | Data stays in OneLake, schema tracked in Git |
| Warehouses | Metadata only | JSON definition | Table definitions, stored procedures |
| Data pipelines | Full | JSON definition | Pipeline activities and configurations |
| Dataflows Gen2 | Partial | M queries | Mashup queries tracked |
| Spark job definitions | Full | Code files | Spark configurations and scripts |
What is NOT tracked in Git: - Actual data in lakehouses and warehouses (only metadata/schema) - Capacity and workspace settings - Permissions and access control - Data source credentials - Refresh schedules
Setting Up Git Integration
Prerequisites
- Repository: Azure DevOps Git or GitHub repository (one branch per workspace)
- Permissions: Workspace Admin or Member role in Fabric, plus write access to the Git repository
- Fabric license: Git integration requires Fabric capacity (F-SKU) or Power BI Premium (P-SKU)
- Tenant setting: "Users can synchronize workspace items with their Git repositories" must be enabled by the Fabric admin
Initial Connection
Step-by-step setup:
- Navigate to Workspace Settings > Git integration
- Select your Git provider (Azure DevOps or GitHub)
- Authenticate and select the repository and branch
- Choose the folder in the repository for this workspace's items
- Click "Connect and sync"
First sync behavior: Fabric compares workspace items with repository contents. If the repo is empty, workspace items are committed to Git. If the repo has content, Fabric shows a merge dialog to resolve conflicts.
Branching Strategy for Fabric Workspaces
The recommended approach maps branches to workspaces in a promotion model:
``` main branch <-> Production Workspace (locked, deploy-only) | develop branch <-> Development Workspace (active development) | feature/* branches <-> Feature Workspaces (isolated experiments) ```
Workspace-branch mapping:
| Workspace | Branch | Purpose | Access Model |
|---|---|---|---|
| Analytics-Prod | main | Production, consumer-facing | Read-only for most users |
| Analytics-Dev | develop | Active development | Development team |
| Analytics-Feature-X | feature/ticket-123 | Isolated feature work | Individual developer |
Key principle: Never develop directly in the production workspace. All changes flow through Git branches and pull requests before reaching production.
Development Workflow
Daily Development Flow
- Developer opens Development workspace connected to the `develop` branch
- Makes changes to semantic models, notebooks, reports, or pipelines
- Reviews changes in the Source Control panel (shows modified items)
- Commits changes with a descriptive message
- Creates pull request in Azure DevOps/GitHub for code review
- Reviewer approves after verifying changes
- Merge to develop triggers sync to Development workspace
- Promote to production through a separate merge to `main`
Working with Semantic Models
Semantic model changes appear in TMDL format — individual files for each table, measure, relationship, and role. This enables meaningful diffs and focused code reviews.
Example TMDL file structure in Git:
``` /semantic-model/ model.tmdl /tables/ Sales.tmdl Products.tmdl Calendar.tmdl /measures/ Total Revenue.tmdl YoY Growth.tmdl /relationships/ Sales-Products.tmdl Sales-Calendar.tmdl /roles/ RegionManager.tmdl /expressions/ ServerParameter.tmdl ```
**Benefits for review:** A reviewer can see exactly which measures changed, which table definitions were modified, or which RLS roles were added — without opening Power BI Desktop.
Working with Notebooks
Notebooks sync as standard .py or .ipynb files, enabling: - Diff viewing for code changes - Linting and static analysis in CI pipelines - Code reuse through shared library imports - Package dependency management through requirements.txt
Conflict Resolution
Conflicts occur when two developers modify the same item on different branches.
Conflict resolution strategies:
| Scenario | Resolution |
|---|---|
| Different items modified | Auto-merge (no conflict) |
| Same item, different properties | Manual merge in Git (text-based TMDL) |
| Same measure modified by two people | Pull request review catches before merge |
| Workspace out of sync with branch | Use "Update from Git" to pull latest changes |
Best practice: Keep feature branches short-lived (1-3 days) to minimize conflict probability.
CI/CD Pipeline Integration
Git integration is the foundation for CI/CD pipelines in Fabric.
Build Validation Pipeline
Trigger on pull requests to validate changes before merge:
```yaml trigger: none pr: branches: include: - develop - main
steps: - task: PowerShell@2 displayName: 'Validate TMDL Schema' inputs: script: | # Validate semantic model definitions dotnet tool install -g TabularEditor.TEditor tEditor semantic-model/ -V
- task: PowerShell@2 displayName: 'Run Best Practice Analyzer' inputs: script: | tEditor semantic-model/ -A bpa-rules.json -W
- task: PowerShell@2 displayName: 'Lint Notebook Code' inputs: script: | pip install flake8 flake8 notebooks/ --max-line-length 120 ```
Deployment Pipeline
After merge to `main`, deploy to production workspace:
Option 1: Git sync — Production workspace connected to `main` branch auto-syncs on merge.
Option 2: Fabric Deployment Pipelines — Use the Fabric deployment pipeline API to promote between workspaces with environment-specific parameter rebinding.
Option 3: Hybrid — Git sync for semantic models and notebooks, Fabric deployment pipelines for reports and dashboards that need visual validation.
Governance and Best Practices
Commit Message Standards
Enforce structured commit messages for traceability:
``` [Item Type] Brief description
Examples: [Model] Add YTD revenue measure with fiscal calendar support [Report] Update executive dashboard with new KPI visual [Notebook] Optimize ETL pipeline for daily refresh performance [Pipeline] Add error handling and retry logic to data ingestion ```
Branch Protection Rules
Configure in Azure DevOps or GitHub:
- Require pull request for merges to develop and main
- Require at least one reviewer approval
- Require build validation to pass before merge
- No direct pushes to main (all changes through PRs)
- Require linked work item for traceability to business requirements
Access Control
| Role | Git Access | Workspace Access | Responsibilities |
|---|---|---|---|
| Developer | Write to feature branches | Member of Dev workspace | Create features, submit PRs |
| Lead Developer | Write to develop | Admin of Dev workspace | Review PRs, approve merges |
| Release Manager | Write to main | Admin of Prod workspace | Approve production deployments |
| Business User | Read only (optional) | Viewer of Prod workspace | Consume reports |
Secrets Management
Never commit secrets to Git. Data source credentials, API keys, and connection strings should be managed through:
- Fabric workspace data source settings (configured per workspace)
- Azure Key Vault references in notebooks and pipelines
- Environment variables in Fabric Spark configurations
- Service principal authentication rather than username/password
Migration from Non-Git Workflows
Organizations with existing Fabric workspaces need a migration path to Git-based development.
Migration steps:
- Inventory — Document all items in the production workspace
- Create repository — Initialize a Git repo with the planned folder structure
- Connect development workspace — Connect a copy of production to Git, perform initial commit
- Validate — Verify all items round-trip correctly (commit to Git, then recreate workspace from Git)
- Establish workflow — Train development team on branching, PR, and review processes
- Connect production — Once workflow is proven, connect production workspace to `main` branch
- Lock down — Remove direct development permissions on production workspace
Timeline: Allow 2-4 weeks for migration including team training and process documentation.
Limitations and Workarounds
| Limitation | Impact | Workaround |
|---|---|---|
| Not all item types fully supported | Some items require manual sync | Track unsupported items separately |
| Data not tracked | Schema changes tracked but not data content | Use data quality frameworks for data validation |
| One branch per workspace | Cannot switch branches in a workspace | Create additional workspaces for additional branches |
| Large repos slow to sync | Initial sync can take minutes | Keep repos focused (one per domain, not one mega-repo) |
| Merge conflicts in JSON | Complex JSON diffs are hard to read | Use TMDL format (one file per object) for semantic models |
Frequently Asked Questions
Can I use GitHub instead of Azure DevOps? Yes. Fabric supports both GitHub and Azure DevOps as Git providers. The functionality is equivalent. Choose based on your organization's existing tooling.
Does Git integration work with Power BI Pro? No. Git integration requires Fabric capacity (F-SKU) or Power BI Premium (P-SKU). Power BI Pro workspaces do not support Git connectivity.
What happens if I disconnect a workspace from Git? The workspace items remain as-is. The Git repository retains all committed content. You can reconnect later and resync.
Can multiple workspaces connect to the same branch? No. Each workspace connects to exactly one branch. This enforces the workspace-per-environment pattern.
How do I handle environment-specific configurations? Use Fabric deployment pipelines for parameter rebinding between environments, or maintain environment-specific configuration files in Git that deployment scripts read during CI/CD.
Next Steps
Git integration is the foundation of professional Fabric development. It enables code review, automated testing, rollback capability, and audit compliance that enterprises require. Our enterprise deployment team helps organizations implement Git-based Fabric workflows including repository design, branching strategy, CI/CD pipeline configuration, and team training. Contact us to modernize your Fabric development process.
**Related resources:** - Azure DevOps CI/CD for Power BI - Power BI Deployment Pipelines - Fabric Workspace Design - Microsoft Fabric Getting Started``` main branch <-> Production Workspace (locked, deploy-only) | develop branch <-> Development Workspace (active development) | feature/* branches <-> Feature Workspaces (isolated experiments) ```
Workspace-branch mapping:
| Workspace | Branch | Purpose | Access Model |
|---|---|---|---|
| Analytics-Prod | main | Production, consumer-facing | Read-only for most users |
| Analytics-Dev | develop | Active development | Development team |
| Analytics-Feature-X | feature/ticket-123 | Isolated feature work | Individual developer |
Key principle: Never develop directly in the production workspace. All changes flow through Git branches and pull requests before reaching production.
Development Workflow
Daily Development Flow
- Developer opens Development workspace connected to the `develop` branch
- Makes changes to semantic models, notebooks, reports, or pipelines
- Reviews changes in the Source Control panel (shows modified items)
- Commits changes with a descriptive message
- Creates pull request in Azure DevOps/GitHub for code review
- Reviewer approves after verifying changes
- Merge to develop triggers sync to Development workspace
- Promote to production through a separate merge to `main`
Working with Semantic Models
Semantic model changes appear in TMDL format — individual files for each table, measure, relationship, and role. This enables meaningful diffs and focused code reviews.
Example TMDL file structure in Git:
``` /semantic-model/ model.tmdl /tables/ Sales.tmdl Products.tmdl Calendar.tmdl /measures/ Total Revenue.tmdl YoY Growth.tmdl /relationships/ Sales-Products.tmdl Sales-Calendar.tmdl /roles/ RegionManager.tmdl /expressions/ ServerParameter.tmdl ```
**Benefits for review:** A reviewer can see exactly which measures changed, which table definitions were modified, or which RLS roles were added — without opening Power BI Desktop.
Working with Notebooks
Notebooks sync as standard .py or .ipynb files, enabling: - Diff viewing for code changes - Linting and static analysis in CI pipelines - Code reuse through shared library imports - Package dependency management through requirements.txt
Conflict Resolution
Conflicts occur when two developers modify the same item on different branches.
Conflict resolution strategies:
| Scenario | Resolution |
|---|---|
| Different items modified | Auto-merge (no conflict) |
| Same item, different properties | Manual merge in Git (text-based TMDL) |
| Same measure modified by two people | Pull request review catches before merge |
| Workspace out of sync with branch | Use "Update from Git" to pull latest changes |
Best practice: Keep feature branches short-lived (1-3 days) to minimize conflict probability.
CI/CD Pipeline Integration
Git integration is the foundation for CI/CD pipelines in Fabric.
Build Validation Pipeline
Trigger on pull requests to validate changes before merge:
```yaml trigger: none pr: branches: include: - develop - main
steps: - task: PowerShell@2 displayName: 'Validate TMDL Schema' inputs: script: | # Validate semantic model definitions dotnet tool install -g TabularEditor.TEditor tEditor semantic-model/ -V
- task: PowerShell@2 displayName: 'Run Best Practice Analyzer' inputs: script: | tEditor semantic-model/ -A bpa-rules.json -W
- task: PowerShell@2 displayName: 'Lint Notebook Code' inputs: script: | pip install flake8 flake8 notebooks/ --max-line-length 120 ```
Deployment Pipeline
After merge to `main`, deploy to production workspace:
Option 1: Git sync — Production workspace connected to `main` branch auto-syncs on merge.
Option 2: Fabric Deployment Pipelines — Use the Fabric deployment pipeline API to promote between workspaces with environment-specific parameter rebinding.
Option 3: Hybrid — Git sync for semantic models and notebooks, Fabric deployment pipelines for reports and dashboards that need visual validation.
Governance and Best Practices
Commit Message Standards
Enforce structured commit messages for traceability:
``` [Item Type] Brief description
Examples: [Model] Add YTD revenue measure with fiscal calendar support [Report] Update executive dashboard with new KPI visual [Notebook] Optimize ETL pipeline for daily refresh performance [Pipeline] Add error handling and retry logic to data ingestion ```
Branch Protection Rules
Configure in Azure DevOps or GitHub:
- Require pull request for merges to develop and main
- Require at least one reviewer approval
- Require build validation to pass before merge
- No direct pushes to main (all changes through PRs)
- Require linked work item for traceability to business requirements
Access Control
| Role | Git Access | Workspace Access | Responsibilities |
|---|---|---|---|
| Developer | Write to feature branches | Member of Dev workspace | Create features, submit PRs |
| Lead Developer | Write to develop | Admin of Dev workspace | Review PRs, approve merges |
| Release Manager | Write to main | Admin of Prod workspace | Approve production deployments |
| Business User | Read only (optional) | Viewer of Prod workspace | Consume reports |
Secrets Management
Never commit secrets to Git. Data source credentials, API keys, and connection strings should be managed through:
- Fabric workspace data source settings (configured per workspace)
- Azure Key Vault references in notebooks and pipelines
- Environment variables in Fabric Spark configurations
- Service principal authentication rather than username/password
Migration from Non-Git Workflows
Organizations with existing Fabric workspaces need a migration path to Git-based development.
Migration steps:
- Inventory — Document all items in the production workspace
- Create repository — Initialize a Git repo with the planned folder structure
- Connect development workspace — Connect a copy of production to Git, perform initial commit
- Validate — Verify all items round-trip correctly (commit to Git, then recreate workspace from Git)
- Establish workflow — Train development team on branching, PR, and review processes
- Connect production — Once workflow is proven, connect production workspace to `main` branch
- Lock down — Remove direct development permissions on production workspace
Timeline: Allow 2-4 weeks for migration including team training and process documentation.
Limitations and Workarounds
| Limitation | Impact | Workaround |
|---|---|---|
| Not all item types fully supported | Some items require manual sync | Track unsupported items separately |
| Data not tracked | Schema changes tracked but not data content | Use data quality frameworks for data validation |
| One branch per workspace | Cannot switch branches in a workspace | Create additional workspaces for additional branches |
| Large repos slow to sync | Initial sync can take minutes | Keep repos focused (one per domain, not one mega-repo) |
| Merge conflicts in JSON | Complex JSON diffs are hard to read | Use TMDL format (one file per object) for semantic models |
Frequently Asked Questions
Can I use GitHub instead of Azure DevOps? Yes. Fabric supports both GitHub and Azure DevOps as Git providers. The functionality is equivalent. Choose based on your organization's existing tooling.
Does Git integration work with Power BI Pro? No. Git integration requires Fabric capacity (F-SKU) or Power BI Premium (P-SKU). Power BI Pro workspaces do not support Git connectivity.
What happens if I disconnect a workspace from Git? The workspace items remain as-is. The Git repository retains all committed content. You can reconnect later and resync.
Can multiple workspaces connect to the same branch? No. Each workspace connects to exactly one branch. This enforces the workspace-per-environment pattern.
How do I handle environment-specific configurations? Use Fabric deployment pipelines for parameter rebinding between environments, or maintain environment-specific configuration files in Git that deployment scripts read during CI/CD.
Next Steps
Git integration is the foundation of professional Fabric development. It enables code review, automated testing, rollback capability, and audit compliance that enterprises require. Our enterprise deployment team helps organizations implement Git-based Fabric workflows including repository design, branching strategy, CI/CD pipeline configuration, and team training. Contact us to modernize your Fabric development process.
**Related resources:** - Azure DevOps CI/CD for Power BI - Power BI Deployment Pipelines - Fabric Workspace Design - Microsoft Fabric Getting Started
Frequently Asked Questions
Which Git providers does Microsoft Fabric support?
Microsoft Fabric supports Azure DevOps (Azure Repos) and GitHub for Git integration. Both providers offer full functionality including branching, pull requests, and branch protection rules. Azure DevOps is more common in enterprise environments with existing Microsoft tooling, while GitHub is popular for teams using open-source workflows.
Does Git integration store my actual data in the repository?
No. Git integration stores artifact definitions and metadata (notebook code, pipeline configurations, semantic model schemas, report layouts) but not actual data. Your data remains in OneLake, warehouses, and other Fabric storage. This keeps repositories lightweight and avoids storing sensitive data in version control.
How do I handle environment-specific configurations between dev and production?
Use Fabric deployment pipelines alongside Git integration. Git manages code versioning and review, while deployment pipelines handle environment-specific configurations like connection strings, parameter values, and data source settings. Connect your dev workspace to a develop branch and production workspace to main, then use pull requests to promote reviewed changes.