How to set up and use Fabric Git integration for your semantic models, and use it with different client tools and metadata formats (like TMDL).
To track and manage changes to your model during development—and to enable better collaboration— you should use source control.
When you develop your model with Tabular Editor, you typically work with metadata files like the model.bim, database.json, or TMDL formats, which allow you to view and manage changes.
For example, two developers can work at the same time on separate branches (or copies) of the model, then merge those branches (and their changes) to a single version in a remote Git repository, like in the Azure Repos service of Azure DevOps.
Figure 1: Without source control (or version control) it’s difficult to track and manage changes, and collaborate. For instance, if two developers are working asynchronously on separate copies of a semantic model, one developer might make changes (3) that overwrite changes of another (2), which causes regression, confusion, and bugs in data and reports for business users; a sad day for all involved (4). You can use source control to improve this.
Figure 2: With source control, it’s easier to track and manage changes, and collaborate on the same model.
Microsoft Fabric also supports Git integration for your semantic models. This means that a Fabric workspace can synchronize with an Azure Repos Git repository, to automatically update with the latest content changes present in that remote repository. You can also write changes to the Fabric workspace (either via Tabular Editor or web authoring of the data model) and then commit those changes to the remote repository straight from the workspace.
This article describes how you can set up and use Fabric Git integration together with Tabular Editor for your Power BI semantic models, irrespective of what storage mode or model metadata format you decide to use.
As of June 28, 2026, Fabric Git integration is the current workspace-level source-control feature in Microsoft Fabric, while support for some item types remains in preview. Check the current Microsoft supported-items list before standardizing a workflow for newer Fabric items.
We have an article series to help you design and build semantic models. Check it out, they’re linked below:
To use Fabric Git integration, you must have the following prerequisites depicted in the diagram.
Figure 3: To use Fabric Git integration, you need certain prerequisites to be fulfilled. Specifically, for your Fabric capacity, an Azure Repos Git repository, and some local tools if you want to support local development.
Git integration is a feature only supported in Fabric. As such, you must have a Fabric capacity (F2 SKU or higher). This feature also works with trial capacities. Additionally, you need to have the following admin settings enabled for users who intend to use Fabric Git integration (the latter two aren’t necessary). Click the links for information from Microsoft Learn about these tenant settings.
Additionally, you need to configure your workspace to use the Fabric capacity and some additional settings.
To use Fabric Git integration, you must have an Azure DevOps organization, and a project within that organization. You should have sufficient rights to manage (or create) an Azure Repos Git repository. This repository will contain the metadata files for your model, or other supported Power BI items like reports or paginated reports (or Fabric items like notebooks).
Download and install tools for working locally
If you intend to develop your content locally and then commit your changes to the Git repository from your machine, you require additional software.
Once you’ve met these prerequisites, you can proceed to set up the Git integration for your semantic model.
In the workspace settings, you should connect your workspace to the Git repository that you created in Azure DevOps.
Figure 4: You must connect a workspace to a branch (and optionally a folder) of your Git repository. You can switch branches without needing to disconnect/reconnect (thus with no risk to losing content).
You can synchronize your workspace to a specific branch and folder of your Git repository. In this article, we don’t use a specific folder or branch (just main), but your choice depends upon how you use and manage your process.
Now, you should either connect to your existing model or create a new model. Optionally, you can enable the new Tabular Model Definition Language (TMDL) format in either Power BI Desktop (for .pbip files, which are required if you use Power BI Desktop) or Tabular Editor.
TMDL is an alternative to the .bim format (sometimes referred to as TMSL). TMDL provides better visibility of changes and an easier time to review pull requests and perform merges (or resolve merge conflicts).
The following diagram illustrates the actions you take to enable .pbip format and/or TMDL format.
Figure 5: In Power BI Desktop, you must enable the .pbip format to use Git integration. You can also optionally enable the TMDL format, which provides better visibility of changes. If you’re using .pbip files, you should enable TMDL. In Tabular Editor, you can choose TMDL as a default serialization format. However, if you want the Power BI service to store your models in TMDL after you deploy them with Tabular Editor via the XMLA endpoint, you need to set a model annotation called __PBI_ServiceStoredInTmdl. It doesn’t matter what the value is of that annotation; it just can’t be empty.
During the preview period for these metadata workflows, several setup steps were required:
__PBI_ServiceStoredInTMDL = "1".You can also set this with a short C# script: Model.SetAnnotation("__PBI_ServiceStoredInTmdl", "1");
Fabric item support changes over time. Before relying on Git integration for Direct Lake or newer Fabric item types, verify that the item and scenario are supported in the current Microsoft documentation.
To get your semantic model into the remote repository, you have different options, depicted in the following diagram.
Figure 6: You have three different options to perform the initial commit and push to get your model into the Git repository when you use Fabric Git integration.
The options are as follows:
You cannot commit model metadata to the repo (like a .bim file or TMDL files, alone) and synchronize that to the workspace as a semantic model. The workspace will not recognize this metadata as a semantic model item; it will be ignored. The full PBIP folder structure needs to be present. You should take one of the three approaches outlined above to set up Git integration.
The following diagram depicts the user interface when you commit either from the workspace or VS Code. Note that the workspace contains only the model, whereas the commit from VS Code also contains a connected report. That’s because it’s currently not possible to develop only a semantic model with Power BI Desktop; it always has the connected report.
Figure 7: You can commit either from the workspace (if you deployed or wrote your changes there first) or from your local repository (if you saved your changes to the local repo).
Once you commit changes from VS Code, you need to then synchronize those changes with your workspace. This synchronization is a necessary step to “deploy” or “publish” those changes, so that they’re visible in the workspace. Similarly, if you want changes made in the workspace (either because you deployed them with Tabular Editor or made them by using web authoring) to be visible in your local content files, you have to sync your local copy of the repository with the remote one.
Essentially, you can now continue working like you normally would. However, you now need to ensure that you regularly batch and commit your changes to the remote repository. You can do this in different ways depending on the tool you use and your preferred process, as depicted in the following diagram.
Figure 8: You can develop your model in Tabular Editor, Power BI Desktop, or a combination of the two. You can write your changes either directly to the workspace, and make your commits there, or save your changes to a local repository, then commit and push those to the remote repo and sync it with the workspace. Note that you can’t make local changes to TMDL files locally, as some changes will make the files unreadable by the workspace upon sync; instead, if you are using TMDL with Tabular Editor during the TMDL public preview, write your changes directly to the workspace and perform your commits, there.
In summary, the diagram outlines four possible options:
The TMDL format and Git integration are still in preview. During this preview, ensure that you test and validate each of these options before you select one that you prefer.
To reiterate, how you work with source control largely depends upon your processes and preferences.
The above steps 1-4 outline how to set up and use Git integration. However, the most challenging part of performing source control effectively is having a good process that everyone on your team follows.
With Git integration, it means that you need to align your branching strategy with how you plan and set up your workspaces, as one workspace can only be synchronized with a single branch (however you can switch which branch it synchronizes with, for instance if you want to use release branches for your content).
For instance, the Microsoft documentation suggests an approach to use a “personal” or “private” workspace for individual developers, where the developers work on separate branches. They merge their changes to a consolidated branch, like the main branch.
Figure 9: One possible way to use Fabric Git integration is to have dedicated private workspaces for developers to use with their own branches. These workspaces allow these developers to create and test content like semantic models using their tool of choice, either Power BI Desktop or Tabular Editor or web authoring in the Fabric portal. Then, in Azure Repos, the developers open a pull request (PR) to have the changes reviewed and merged into the main branch, which synchronizes to a dedicated development workspace. From there, the team can use deployment pipelines to shuttle the model onwards for testing and quality control, then release to production.
To reiterate and emphasize: source control is only as effective as its underlying process, and how well people adhere to that process. Getting value from something like Git integration requires that you have a clearly defined way of using it that helps you and your team be more effective. For instance source control can help you to collaborate or enable use-cases for your semantic models, like automated validation or rollback to previous versions in the event that proverbial moon rocks hit the fan.
Git integration is a feature long awaited by enterprise Power BI teams, or teams who just want to better track and manage changes or collaborate on the same model. You can use Git integration with both Tabular Editor and Power BI Desktop–even interchangeably. With the new TMDL format, you also have better visibility of what changed, and a smoother experience to manage and merge those changes. For Direct Lake and newer Fabric item types, check current support before deciding which deployment path to standardize.
Take your semantic models further with Tabular Editor.
Give Tabular Editor a spin