Fabric Git integration versions a workspace. It does not version everything in that workspace, and the difference is where recovery plans quietly go wrong.
Fabric does flag it. After you connect, the workspace shows a Git status column against every item, and one of the six possible states is Unsupported item. The information is there, sitting in plain sight.
The problem is that it sits in the workspace pane, and the place people actually look when they are committing is the source control panel. That panel lists changed items as new, modified, deleted, conflict or same-changes. Unsupported is not one of those states, because unsupported items are not changes. They are absences. So the commit completes, the panel reads clean, and nothing in that workflow suggests the workspace is only partly covered.
This article covers what Fabric Git integration actually versions, the one item type that catches established estates, and what the uncovered tail costs when you have to rebuild it.
What Git integration connects, and at what level
Fabric Git integration operates at the workspace level, not the item level. You connect a workspace to a branch, and the workspace structure, including subfolders up to ten levels deep, is preserved in the repository. The folder layout your team works in is the folder layout in Git.
Three Git providers are supported, in cloud form only: Azure DevOps, GitHub and GitHub Enterprise. GitHub Enterprise Server on a private network, on a custom domain, or behind an IP allowlist is not supported. For most Fabric estates this is academic, since the platform is already cloud. For a regulated client insisting source control stays inside their own network, it is a design constraint worth surfacing early.
Where the gap is actually visible
Two surfaces, and they answer different questions.
| Surface | What it shows | Where the unsupported items appear |
| Workspace Git status column | The sync state of every item: synced, conflict, unsupported item, uncommitted changes, update required, or needs updating to the last commit | Here, explicitly labelled |
| Source control panel | Only items that differ between workspace and branch, as new, modified, deleted, conflict or same-changes | Nowhere. They are not changes, so they never appear |
That table is the whole article in miniature. An engineer who commits, sees zero outstanding items and moves on has not done anything wrong. They have used the surface designed for committing. The coverage question is answered on a different screen, and nothing prompts them to go and look at it.
We believe this is the single most common false assurance in Fabric estates: a workspace connected to Git, described in the runbook as versioned, where nobody has ever opened the Git status column and counted.
The supported items list, and the trap inside Dataflow Gen2
Most item types sync. The list is long and it grows most months, which is itself a reason to check rather than to memorise.
| Area | Syncs to Git | Treat with care |
| Data engineering | Environment, Lakehouse, Notebooks, Spark Job Definitions, GraphQL, User Data Functions | |
| Data Factory | Pipeline, Copy Job, Mirrored database, Mount ADF, Dataflow Gen2 (with a condition, below) | Mirrored Snowflake, Airflow, dbt Job and Operations Agent are still preview |
| Data warehouse | Warehouse, Mirrored Azure Databricks Catalog | |
| Real-Time Intelligence | Eventhouse, Eventstream, KQL database, KQL queryset, Real-Time Dashboard, Activator, Maps | Event Schema Set, Digital twin builder and Anomaly detection are still preview |
| Power BI | Reports, semantic models, paginated reports, org apps, metrics sets | Exclusions apply, below |
| Databases | SQL database | Cosmos database is still preview |
| Data science | Data Agents | Machine learning experiments and models are still preview |
The Power BI exclusions are the ones to check. Reports connected to semantic models hosted in Azure Analysis Services or SQL Server Analysis Services are out, as are reports exported from Power BI Desktop that depend on semantic models in My Workspace. Semantic models exclude push datasets, live connections to Analysis Services, and model v1. An estate with a long Analysis Services history will have more of these than anyone expects.
Dataflow Gen2 is the one that catches established estates, and the reason is easy to miss. Microsoft’s guidance states that all new Dataflow Gen2 items are created with CI/CD and Git integration support by default. New ones. Dataflow Gen2 items created before that capability existed do not carry CI/CD support and cannot be committed, and there is no switch that retrofits it. They have to be recreated.
So a greenfield workspace built this year will report full Dataflow Gen2 coverage, and a workspace that has been running since 2024 will not, while both look identically connected. The estates most likely to need recovery are the ones least likely to be covered.
Even where it is supported there is a manual step worth knowing: after syncing from Git or running a deployment pipeline, you have to open the dataflow and save it in the editor to trigger the background publish, or call the on-demand publish API. A restored dataflow is not a running dataflow until someone does that.
What the uncovered tail actually costs
In our engagements the uncovered items are rarely exotic. They are ordinary artefacts that happen to predate a capability, and they are frequently integral to how the estate runs, which makes going without them a poor option.
Recreating one is not slow. We have seen it take fifteen to twenty minutes, copying and updating the definition from another workspace. If the cost were only time, this would be a footnote.
The cost is elsewhere, in three places:
Documentation. A manual rebuild is only repeatable if someone wrote down what the artefact contained. Git was supposed to be that record. For uncovered items it is not, so the record is whatever a person maintained by hand, and it is usually stale.
Sequencing. Artefacts have dependencies. Rebuilding them in the wrong order produces a workspace that looks complete and does not run. Git restores respect the definitions; a manual rebuild respects only the order the person doing it happens to choose.
Access and audit, which is the real problem. Recreating an artefact by hand in production requires edit and create rights on the production workspace. That directly contradicts the access model most organisations have spent years putting in place, and it puts a manual change into production outside the audit trail every other change goes through. The recovery procedure and the access policy cannot both be followed. In practice one of them gets quietly suspended during an incident, which is exactly when you least want it to be.
That is the argument for finding the uncovered items now, in daylight, rather than discovering them mid-recovery with a change advisory board on the phone.
What this means for disaster recovery
Our Fabric disaster recovery article set out a planning figure of fifteen minutes to two hours to restore artefacts, on the explicit condition that those artefacts are git controlled. That condition is doing a lot of work.
For uncovered items the restore path is not the documented one. It is manual rebuild, at rebuild pace, through the access contradiction described above. Publishing a single blended recovery time across both populations is not a recovery time, it is an average of two unrelated numbers.
The correction is to split the inventory and publish both:
- Items covered by Git integration. Restore path is the documented one.
- Items not covered. Restore path is manual, with its own estimate and its own access exception agreed in advance.
A recovery plan that names its manual tail is credible. One that averages it away fails at the worst possible moment.
How to check a workspace before you rely on it
Under an hour per workspace, and worth doing before any recovery commitment is made.
- Open the Git status column in the workspace pane and count anything marked *Unsupported item*. This is the check, and it is the one nobody runs. Do not use the source control panel for this; it will not show them.
- Check every Dataflow Gen2 item for whether it was created with CI/CD support. Age of the workspace is the fastest proxy.
- Check the Power BI items for Analysis Services connections, My Workspace dependencies, push datasets and model v1.
- Confirm the Git provider is a supported cloud form, particularly with GitHub Enterprise, where private networks, custom domains and IP allowlists are all unsupported.
- Record the uncovered items in the recovery runbook with their own restore estimate and a named access exception.
Permissions deserve a check of their own, because they produce confusing failures during a rehearsal. What you can do depends on your role in the workspace and your permissions in the repository at the same time, so an engineer who can commit in one may be blocked in the other. Note also that from December 2026, users without read-write permissions on workspace items cannot use Git integration at all, which will affect anyone relying on a read-only service account.
Git integration and deployment pipelines are not the same control
The two are complementary and frequently conflated. Git integration versions the contents of a workspace against a branch. Deployment pipelines promote content between workspaces, development to test to production.
With pipelines and no Git integration you can promote, but you cannot recover a deleted item or revert a bad change. With Git integration and no pipelines you can recover, but every promotion is manual. Neither alone is a complete lifecycle.
One constraint applies to both: a workspace holds a maximum of 1,000 items, and syncing a branch containing more than that will fail. Estates approaching the limit need splitting across workspaces and branches before it becomes an incident rather than a design task.
Where to start
Fabric Git integration is the right control and it should be switched on. The mistake is treating the connection as the finish line.
Connect the workspace, then open the Git status column and count the unsupported items. That number, not the green commit, is what your recovery plan is actually built on.
Veratas runs Microsoft Fabric platform assessments that include exactly this inventory, alongside the wider data consulting work that decides how an estate should be structured in the first place.
If you have a Fabric workspace connected to Git and nobody has confirmed what it covers, talk to our team. It is a short exercise and the answer is usually not what the runbook says.
Frequently asked questions
Does connecting a workspace to Git mean everything in it is versioned? No. Unsupported item types are ignored. They are not synced and not deleted, and they cannot be committed. Fabric marks them with an *Unsupported item* status in the workspace Git status column, but they never appear in the source control panel, so a clean commit tells you nothing about coverage.
Where do I see which items are not covered? In the workspace pane, in the Git status column, not in the source control panel. The source control panel only lists items that differ between the workspace and the branch.
Why can I not commit my Dataflow Gen2 items? Only Dataflow Gen2 items created with CI/CD and Git integration support can be committed, which is the default for new items. Items created before that capability existed cannot be retrofitted and have to be recreated.
Are Power BI reports and semantic models covered? Yes, with exclusions. Reports connected to semantic models in Azure Analysis Services or SQL Server Analysis Services are excluded, as are semantic models using push datasets, live connections to Analysis Services, or model v1.
Do I still need deployment pipelines if I have Git integration? Yes, for most estates. Git integration versions a workspace and lets you revert. Deployment pipelines promote content between workspaces. They solve different problems.
How does this affect my Fabric recovery time objective? Only covered items restore on the documented path. Uncovered items are rebuilt by hand, which takes fifteen to twenty minutes each in our experience but also requires create rights on the production workspace. Split the inventory and publish both numbers.
Azure and Business Intelligence Architect with 17+ years of experience delivering cloud data and analytics solutions. Focus areas include Azure data platforms, ETL and ELT architecture, and enterprise BI on Microsoft Azure.