How to Connect a Microsoft Fabric Workspace to Git

João Barros 12 de July de 2026 4 min read

Connecting a Microsoft Fabric workspace to Git gives you real version control: every report, notebook or pipeline gets history, review and the ability to roll back when something goes wrong. It is also the foundation for several people working in the same workspace without overwriting each other.

Prerequisites

A Microsoft Fabric workspace assigned to a Fabric (or Premium) capacity, and the Admin role on that workspace.
A repository in Azure DevOps (Azure Repos) or GitHub. For Azure DevOps, the account must belong to the same Microsoft Entra ID tenant.
A target branch (for example main) and, optionally, a folder inside the repository.
Git integration enabled in the tenant settings by the Fabric administrator.

Step 1: Prepare the repository

Create (or pick) a repository and make sure it has at least one initialized branch. A repository with no commits cannot be connected. Reserve a folder just for Fabric, for example /fabric: if the repository also stores code from other teams, your workspace items stay tidy.

Tip: use one folder per environment (for example /fabric/dev) if you later plan to connect different workspaces to the same repository.

Step 2: Connect the workspace to Git

In the workspace, open Workspace settings and go to the Git integration tab. Pick the provider (Azure DevOps or GitHub), sign in and fill in the fields: organization, project, repository, branch and folder. Then click Connect and sync.

On the first connection, Fabric compares what is in the workspace with what is in the repository folder. If one side is empty, the sync is immediate; if both have content, you must choose which one wins.

Step 3: Make the first commit

Once connected, a Source control button appears at the top of the workspace. Open it: supported items (reports, semantic models, notebooks, pipelines, lakehouses and others) show up as Uncommitted. Select the ones you want to version, write a clear message and click Commit.

In the repository, each item becomes a folder holding its definition as text:

/fabric
  /Vendas.Report
      .platform
      definition.pbir
  /Vendas.SemanticModel
      .platform
      definition/
  /Ingestao.Notebook
      .platform
      notebook-content.py

The .platform file stores the item metadata (type, name and logical identifier). Do not edit it by hand.

Step 4: Work on a separate branch

To develop without touching the main workspace, use Branch out to another workspace in the Source control panel. Fabric creates a new branch from the current one and a new workspace already connected to it. Make your changes, commit, then open a pull request in Azure DevOps or GitHub, exactly as you would with regular code.

Step 5: Update from Git and resolve conflicts

When someone merges into your branch, the Source control panel shows items as Update required. Click Update all to bring the changes into the workspace.

If the same item was changed on both sides, Fabric flags a conflict and asks you which version to keep: the workspace one or the Git one. This is the most common error for beginners, and a simple rule avoids it: update before you start working, and commit in small steps.

Step 6 (optional): Automate with the Fabric REST API

If you want the commit inside a CI/CD pipeline, Fabric exposes Git endpoints. A minimal example that pushes everything pending:

POST https://api.fabric.microsoft.com/v1/workspaces/{workspaceId}/git/commitToGit
Authorization: Bearer <token>
Content-Type: application/json

{
  "mode": "All",
  "comment": "Automated commit from the pipeline"
}

There are equivalent endpoints for updateFromGit and for reading the status, useful to check whether an environment is in sync before promoting changes.

Verify the result

Check three things. First, in the repository: the configured folder has one subfolder per item and a commit with your message. Second, in the workspace: the Source control panel shows Synced with no pending changes. Third, run a real test: rename a report, confirm it shows as Modified, commit it and look at the diff in Git.

Conclusion

With the workspace connected to Git you get history, pull request reviews and a natural path to CI/CD with deployment pipelines. The next step is to create separate workspaces for dev, test and production, each connected to its own branch. Before you move on, one question to think about: if a report were deleted by mistake today, how long would it take you to get it back?