Edit

Share via

What is Microsoft Fabric Git integration?

  • Article

This article explains to developers how to integrate Git version control with the Microsoft Fabric Application lifecycle management (ALM) tool.

Note

Some of the items for Git integration are in preview. For more information, see the list of supported items.

Git integration in Microsoft Fabric enables developers to integrate their development processes, tools, and best practices straight into the Fabric platform. It allows developers who are developing in Fabric to:

  • Backup and version their work
  • Revert to previous stages as needed
  • Collaborate with others or work alone using Git branches
  • Apply the capabilities of familiar source control tools to manage Fabric items

The integration with source control is on a workspace level. Developers can version items they develop within a workspace in a single process, with full visibility to all their items. The workspace structure, including subfolders, is preserved in the Git repository.

See the list of supported items.

Privacy information

Before you enable Git integration, make sure you review the following privacy statements:

Supported Git providers

The following Git providers are supported:

Supported items

The following items currently support Git integration:

If the workspace or Git directory has unsupported items, it can still be connected, but the unsupported items are ignored. They aren't saved or synced, but they're not deleted either. They appear in the source control panel but you can't commit or update them.

Considerations and limitations

General Git integration limitations

  • The authentication method in Fabric must be at least as strong as the authentication method for Git. For example, if Git requires multifactor authentication, Fabric needs to require multifactor authentication as well.
  • Power BI Datasets connected to Analysis Services aren't supported at this time.
  • Submodules aren't supported.
  • Sovereign clouds aren't supported.

GitHub Enterprise limitations

Some GitHub Enterprise settings aren't supported. For example:

  • IP allowlist

Workspace limitations

  • Only the workspace admin can manage the connections to the Git Repo such as connecting, disconnecting, or adding a branch.
    Once connected, anyone with permission can work in the workspace.
  • Workspaces with template apps installed can't be connected to Git.
  • MyWorkspace can't connect to a Git provider.

Branch and folder limitations

  • Maximum length of branch name is 244 characters.
  • Maximum length of full path for file names is 250 characters. Longer names fail.
  • Maximum file size is 25 MB.
  • Folder structure is maintained up to 10 levels deep.
  • You can’t download a report/dataset as .pbix from the service after deploying them with Git integration.
  • If the item’s display name has any of these characteristics, The Git folder is renamed to the logical ID (Guid) and type:
    • Has more than 256 characters
    • Ends with a . or a space
    • Contains any forbidden characters as described in directory name limitations
  • When you connect a workspace that has folders to Git, you need to commit changes to the Git repo if that folder structure is different.

Directory name limitations

  • The name of the directory that connects to the Git repository has the following naming restrictions:

    • The directory name can't begin or end with a space or tab.
    • The directory name can't contain any of the following characters: "/: <>\*?|

  • The item folder (the folder that contains the item files) can't contain any of the following characters: ":<>\*?|. If you rename the folder to something that includes one of these characters, Git can't connect or sync with the workspace and an error occurs.

Branching out limitations

  • Branch out requires permissions listed in permissions table.
  • There must be an available capacity for this action.
  • All workspace and branch naming limitations apply when branching out to a new workspace.
  • Only Git supported items are available in the new workspace.
  • The related branches list only shows branches and workspaces you have permission to view.
  • Git integration must be enabled.
  • When branching out, a new branch is created and the settings from the original branch aren't copied. Adjust any settings or definitions to ensure that the new meets your organization's policies.
  • When branching out to an existing workspace:
    • The target workspace must support a Git connection.
    • The user must be an admin of the target workspace.
    • The target workspace must have capacity.
    • The workspace can't have template apps.
  • Note that when you branch out to a workspace, any items that aren't saved to Git can get lost. We recommend that you commit any items you want to keep before branching out.

Sync and commit limitations

  • You can only sync in one direction at a time. You can’t commit and update at the same time.
  • Sensitivity labels aren't supported and exporting items with sensitivity labels might be disabled. To commit items that have sensitivity labels without the sensitivity label, ask your administrator for help.
  • Works with limited items. Unsupported items in the folder are ignored.
  • Duplicating names isn't allowed. Even if Power BI allows name duplication, the update, commit, or undo action fails.
  • B2B isn’t supported.
  • Conflict resolution is partially done in Git.
  • During the Commit to Git process, the Fabric service deletes files inside the item folder that aren't part of the item definition. Unrelated files not in an item folder aren't deleted.
  • After you commit changes, you might notice some unexpected changes to the item that you didn't make. These changes are semantically insignificant and can happen for several reasons. For example:
    • Manually changing the item definition file. These changes are valid, but might be different than if done through the editors. For example, if you rename a semantic model column in Git and import this change to the workspace, the next time you commit changes to the semantic model, the bim file will register as changed and the modified column pushed to the back of the columns array. This is because the AS engine that generates the bim files pushes renamed columns to the end of the array. This change doesn't affect the way the item operates.
    • Committing a file that uses CRLF line breaks. The service uses LF (line feed) line breaks. If you had item files in the Git repo with CRLF line breaks, when you commit from the service these files are changed to LF. For example, if you open a report in desktop, save the project file (.pbip) and upload it to Git using CRLF.
  • Refreshing a semantic model using the Enhanced refresh API causes a Git diff after each refresh.

Related content