Maintain a Data Analytics Solution · Topic 4 of 5

Git Integration, PBIP and Deployment Pipelines

Connect a Fabric workspace to Git, save Power BI Desktop projects as .pbip with TMDL, and promote content with deployment pipelines and deployment rules.

  • 5 min
In a nutshell
  • Git integration supports Azure DevOps and GitHub; one branch per workspace; Admin connects it.
  • Git stores item definitions, never table data or imported model data.
  • A .pbip project splits into a .SemanticModel folder and a .Report folder; TMDL is the readable model format.

What it is

The analytics development lifecycle moves content from a developer to production without breaking it. Fabric gives you three tools for this.

  • Git integration links a workspace to a branch in Azure DevOps or GitHub, so item definitions are versioned.
  • Power BI Desktop projects (.pbip) save a report and semantic model as text files that Git can compare and merge.
  • Deployment pipelines copy items from one stage workspace to the next, such as Development, Test and Production.
Power BI Desktopsave as .pbipcommitGit branchsyncDev workspacedeployTestdeployProduction

How it works

Git integration for a workspace

A workspace Admin opens Workspace settings > Git integration, chooses Azure DevOps or GitHub, and picks the repository, branch and folder. Each workspace connects to one branch at a time.

After that, the Source control pane shows the state of each item:

Action or stateMeaning
CommitSave workspace changes to the branch
UpdateBring changes from the branch into the workspace
UncommittedThe item changed in the workspace but not in Git
Update requiredThe branch has newer changes than the workspace
ConflictThe same item changed in both places

Git stores item definitions only, such as the model metadata, report layout, notebook code or pipeline JSON. Table data in a lakehouse or warehouse, and data imported into a semantic model, are not stored in the repository.

A common pattern is one feature branch per developer. Each developer works in a private workspace or locally, opens a pull request, and the shared Development workspace is updated from the main branch after the merge.

Power BI Desktop projects (.pbip)

File > Save as with the Power BI project type writes a folder instead of a single .pbix file:

Sales.pbip
Sales.SemanticModel/
    definition.pbism
    definition/            model in TMDL, one file per table
    .pbi/cache.abf         local data cache, ignored by Git
Sales.Report/
    definition.pbir
    definition/            report pages and visuals
.gitignore

The semantic model can be stored in TMDL (Tabular Model Definition Language), which is readable and gives clean diffs. A measure in a TMDL table file looks like this:

table Sales

	measure 'Total Sales' = SUM(Sales[Amount])
		formatString: #,0.00

	column Amount
		dataType: decimal
		sourceColumn: Amount

The .gitignore excludes the cached data and local settings, so only definitions reach the repository. The folders use the same format as Fabric Git integration, so a developer can edit in Power BI Desktop, commit, and let the workspace update from the branch.

Deployment pipelines

A deployment pipeline has between two and ten stages; the default is Development, Test and Production. Each stage is assigned one workspace, and a workspace belongs to only one pipeline.

FeatureWhat it does
CompareShows which items differ between two stages
Deploy all or selective deployCopies all items, or only the ones you pick, to the next stage
Deployment rulesChange data source connections or parameter values for an item in the target stage
Auto-bindingA deployed report connects to the semantic model in its own stage, not the previous one

Deployment copies metadata, not data. After the first deployment of an import semantic model to Test, you refresh it there so it holds data.

To deploy, a user needs access to the pipeline and at least Contributor on the source and target workspaces.

A worked example

A team builds a sales model against a development warehouse. Production must read the production warehouse.

  1. Developers save the report as .pbip, commit to feature branches and merge to main.
  2. The Development workspace is connected to main and updated after each merge.
  3. A deployment pipeline promotes Development to Test and then to Production.
  4. On the Test and Production stages, a deployment rule changes the semantic model's warehouse connection (or a server parameter) to the right environment.
  5. After deployment, each stage's model is refreshed.
Exam tip

Git answers "who changed what and can we roll back". Deployment pipelines answer "promote between environments with different connections".

How the exam asks about this

  • "Developers must compare model changes line by line in pull requests." Save as .pbip with TMDL and use Git integration.
  • "The Production model must connect to a different data source than Development." A deployment rule on the Production stage.
  • "Deploy only the updated report, not the whole workspace." Selective deployment.

What to remember for the exam

  • Git integration supports Azure DevOps and GitHub; one branch per workspace; Admin connects it.
  • Git stores item definitions, never table data or imported model data.
  • A .pbip project splits into a .SemanticModel folder and a .Report folder; TMDL is the readable model format.
  • Deployment pipelines have 2 to 10 stages, one workspace per stage, one pipeline per workspace.
  • Deployment rules change data sources and parameters per stage; deployments copy metadata only.
Watch out

Deploying a semantic model does not copy its data. A newly deployed import model in Test or Production is empty until it is refreshed.

Common mistakes

Putting .pbix files in Git and expecting useful diffs. A .pbix is a binary file. Save as .pbip so the model and report become text files.

Editing data source names by hand in each stage. Use deployment rules or parameters so every deployment sets the right connection automatically.

Expecting Git to back up lakehouse tables. Git versions definitions. Data recovery depends on the data store, such as Delta table history, not on the repository.

Check yourself

  • What is stored in Git when a workspace uses Git integration?

    Item definitions such as model metadata, report layout and notebook code. Table data and imported data are not stored.

  • How does a deployment pipeline point Production at a production database?

    With a deployment rule on the Production stage that changes the data source or a parameter value.

  • Which file from a .pbip project is excluded from Git by default and why?

    The local data cache (cache.abf), because it holds data, not definitions, and would make the repository large.

Topic 4 of 5 in Maintain a Data Analytics Solution

Test yourself on Maintain a Data Analytics Solution

The full Microsoft DP-600 question bank has 648 questions, with timed practice exams and an explanation for every answer.

This study guide is independent and is not affiliated with, endorsed by, or sponsored by Microsoft. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.