Almanac
Microsoft/power-biPower Platform

Consultant KB for Microsoft Power BI: semantic models, DAX and modelling, Power Query and dataflows, reports and visuals, the service and workspaces, capacity and performance, embedding and integration, governance and security, ALM and deployment, and licensing, plus cross-cutting decision guides. Scoped to Power BI, with Microsoft Fabric covered where it touches Power BI directly. Implementation notes, configuration decisions and the gotchas that bite on real projects. Populated by the daily author agent from the Power BI release plans, docs repo and product blog, plus the author's own consultant notes.

power-bi/09-alm-and-deployment/feature-git-integration.md
feature-git-integration.mdv1 · history
CurrentApplies to ServiceUpdated last monthSource Microsoft Learn ↗

What it does

Connects a Fabric workspace to a branch in a Git repository so that item definitions are serialised into source control and can be committed, updated and reverted from inside the workspace. The connection is at workspace level, not item level — you version everything supported in that workspace as one unit.

Key facts

  • Supported providers are Azure DevOps, GitHub and GitHub Enterprise, cloud-hosted only. Self-hosted Git servers aren't on the list.
  • Workspace subfolder structure is preserved in the repo, so the folder layout you choose in the workspace becomes your repo layout.
  • Power BI item support is currently flagged preview: report, semantic model, paginated report, org app and metrics set. Notable exclusions are push datasets, live connections to Analysis Services, model v1 semantic models, and reports whose model lives in Azure AS, SQL Server AS or someone's My Workspace.
  • Unsupported items in the workspace or repo are ignored rather than deleted. They show in the source control panel but can't be committed or updated.
  • Connecting, syncing, disconnecting and switching branch are Admin operations. Members and Contributors can commit and update; there's a workspace setting that also lets Contributors with write access on all items change branch. Viewers see nothing Git-related at all.
  • From 1 November 2026, users without read-write permission on workspace items can't use Git integration. Sensitivity labels and protection policies can therefore remove someone's Git access as a side effect.
  • Azure Repos in a different region from the workspace need the cross-geo export tenant setting turned on. GitHub isn't subject to that restriction.
  • Conflicts are resolved per item: accept incoming from Git, keep the workspace version, revert either side to the last synced state, or fix it in Git directly. Commit is disabled while a conflict is outstanding.
  • "Branch out to another workspace" creates a new branch and a new workspace together, which is the supported way to do isolated feature work.

When to use / skip

Use it where the client has a platform team, an existing repo culture and content that matters enough to justify pull requests. The value is real code review, branch policies and a history you can blame — none of which deployment pipelines give you.

Be honest about the cost. Branch-per-developer means workspace-per-developer, which means capacity and admin overhead the client hasn't budgeted for. For a finance team of three analysts, Git integration is ceremony they'll abandon in a month. Match the tooling to the operating model, not to the maturity you wish they had.

Configuration decisions

  • Branching strategy first: branch-per-feature with a workspace each, or a single shared development branch. This determines how many workspaces you need and is expensive to change later.
  • Which repo and which directory. One repo per solution keeps history readable; one repo for the whole estate keeps admin simple. Pick deliberately.
  • Whether Git or deployment pipelines drives production. Running Git into dev and pipelines from dev to prod is a common and workable split — but write it down.
  • Who holds workspace Admin, given that's the gate on connecting and branch switching.
  • Whether the Allow users with at least Contributor role to change Git branch workspace setting is on, and what that means for accidental branch switches in a shared workspace.

Gotchas

  • The first sync is the awkward one. If both the workspace and the branch have content, you're immediately in conflict territory before anyone has done any work.
  • Reverting the workspace to the last synced state loses everything uncommitted. People discover this after an afternoon of unsaved changes.
  • Semantic models in Git are still marked preview and the exclusion list is longer than clients expect. A live-connected report to an Azure AS model simply won't version.
  • Diffs on report files are readable but not friendly. Reviewing a visual layout change in a pull request is not the experience developers assume from the word "diff".
  • The November 2026 permission change will quietly break workflows for anyone relying on read-only users pulling from Git. Check that before it bites.

Consultant notes

  • Ask who reviews pull requests before you propose this. Git integration with nobody reviewing is version control with extra steps.
  • Pair it with PBIP so that Desktop-authored work lands in the repo in the same shape as service-authored work. Half the value evaporates if the two paths produce different files.
  • Warn the client that Fabric writes the item definitions — the repo layout isn't yours to reorganise freely.
  • Where the client is nervous, start read-only: connect one workspace, commit, and let them watch history accumulate for a sprint before you commit to branching.

Recheck the supported-items list and the November 2026 permission change before quoting any of this to a client

Was this accurate?
Related
Deployment pipelines09-alm-and-deploymentXMLA endpoint09-alm-and-deploymentOneLake and workspace items05-service-and-workspacesDataflows03-power-query-and-dataflowsWorkspace and model topology11-decision-guidesSemantic model fundamentals01-semantic-models