2.4 Lifecycle: Git Integration & PBIP

Treating Analytics Content as Code

Quick Answer: Fabric Git integration links a workspace to an Azure DevOps or GitHub repository so Fabric items are versioned with Commit, Update, and Sync actions. PBIP (Power BI Project) saves reports and semantic models as plain-text folders using TMDL and PBIR, making them human-readable, diffable, and reviewable in pull requests. Git handles versioning and collaboration; it does not promote content between environments — that is a deployment pipeline.

Fabric Git Integration

Git integration brings software-engineering discipline to analytics development:

• A workspace is connected to a single repository and a single branch (one-to-one). You cannot point one workspace at two branches simultaneously.
• Commit pushes workspace changes up to the branch; Update pulls repo changes down into the workspace; Sync reconciles the two directions. The Source control pane shows each item's status: Synced, Uncommitted, Update needed, or Conflict.
• Connecting a workspace to a feature branch (the Branch out to new workspace action) gives a developer an isolated working environment so changes never disturb shared dev content.
• Supported item definitions — semantic models, reports, notebooks, data pipelines, lakehouses (definition only), and more — are serialized into the repo so history, code review, and rollback become possible.

Typical Branching Flow

PBIP — Power BI Project Files

A .pbix file is a single binary blob: opaque to Git, with no meaningful line-level diffs — Git can only say "the file changed." PBIP solves this by saving a Power BI project as a folder of plain-text files:

• The semantic model is stored in TMDL (Tabular Model Definition Language) — readable, line-by-line diffable text where each table, measure, and relationship is its own entry.
• The report is stored in the PBIR format — its layout and visual definitions are also text/JSON-based.
• Because everything is text, pull-request reviewers see exactly what changed in a single measure, a relationship, or a visual, and changes merge like code with proper conflict resolution.

PBIP is enabled in Power BI Desktop (File > Save as > Power BI project) and is the on-disk format that Fabric Git integration commits for Power BI items.

Git vs Deployment Pipelines (Don't Confuse Them)

A recurring exam trap is choosing Git when the requirement is moving content between dev/test/prod. Keep the line crisp:

Git integration = source control and collaboration. Deployment pipeline = environment promotion. They complement each other in a complete ALM (application lifecycle management) story, but each answers a different question, and the wrong-answer set always offers the other one.

Resolving Conflicts and Item Status

When both the workspace and the branch change the same item, the Source control pane flags a Conflict. Fabric does not silently overwrite; you must choose which version wins, then commit the resolution. Knowing the four statuses helps you read scenario questions precisely:

Supported and Unsupported Items

Not every Fabric item is fully Git-serializable. Semantic models, reports, notebooks, data pipelines, and many definitions are supported; some item types or their data are not version-controlled (Git stores definitions, not lakehouse table data). For the exam, the durable rule is: Git tracks the code/definition of items, while the actual data warehoused in a lakehouse or warehouse is not committed. This is why a fresh Update of a workspace re-creates item definitions but does not restore deleted rows of data.

A Complete ALM Picture

The mature pattern combines both tools. Developers each branch out to isolated workspaces, commit PBIP-serialized changes, and merge via pull request into main. The shared Development workspace is connected to main and Updates from it. From there a deployment pipeline promotes the validated content through Test and Production, applying deployment rules so each stage hits the right data source. Git never touches Test or Prod data sources, and the pipeline never reviews code — they are deliberately separate concerns.

When a question describes "review every change" or "roll back to a prior version," think Git; when it describes "move the approved report to production," think deployment pipeline. Recognizing which verb the scenario uses — review/rollback/branch vs promote/deploy — is the fastest route to the correct answer in this lifecycle topic.