This summary is produced by the author, and not by AI.
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.
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.
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.
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.
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.
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.
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.
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.
In summary, the diagram outlines four possible options:
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.
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.
Keep Fabric model changes reviewable with Tabular Editor 3 and Git.
Give Tabular Editor a spin