2.4 Lifecycle: Git Integration & PBIP
Key Takeaways
- Fabric Git integration connects a workspace to an Azure DevOps or GitHub repository so items are version-controlled, with commit, update, and sync operations.
- Each workspace connects to one branch; branching out to a feature branch creates an isolated workspace for safe development.
- PBIP (Power BI Project) saves a report and semantic model as plain-text folders (TMDL/PBIR), making them diffable and reviewable in pull requests.
- Git integration tracks supported Fabric item definitions, enabling code review, change history, and rollback before promotion.
- Source control (Git) handles versioning and collaboration; promotion across environments is the deployment pipeline's job, not Git's.
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:
- A workspace is connected to a repository and a single branch.
- Commit pushes workspace changes to the branch; Update pulls repo changes into the workspace; Sync reconciles the two. The UI shows each item's status (Synced, Modified, Conflict).
- Connecting a workspace to a feature branch (branching out) gives a developer an isolated working environment so changes do not disturb shared dev content.
- Supported item definitions (semantic models, reports, notebooks, and more) are serialized into the repo so history, code review, and rollback are possible.
Typical Branching Flow
| Step | Action |
|---|---|
| 1 | Developer branches out from main to a feature branch and a new isolated workspace |
| 2 | Makes changes, commits to the feature branch |
| 3 | Opens a pull request into main; reviewers diff the plain-text files |
| 4 | PR merged; the shared dev workspace updates from main |
| 5 | A deployment pipeline later promotes the validated content to test and prod |
PBIP — Power BI Project Files
A .pbix file is a single binary blob: opaque to Git, with no meaningful diffs. PBIP solves this by saving a Power BI project as a folder of plain-text files:
- Semantic model is stored in TMDL (Tabular Model Definition Language) — readable, line-by-line diffable text.
- Report is stored in the PBIR format — its definition is also text-based.
- Because everything is text, pull request reviewers can see exactly what changed in a measure, relationship, or visual, and changes can be merged like code.
Git vs Deployment Pipelines (Don't Confuse Them)
A recurring exam trap: choosing Git when the requirement is moving content between dev/test/prod. Git integration = source control, collaboration, history, rollback. Deployment pipeline = environment promotion. They complement each other but solve different problems.
A developer must make extensive changes to a shared development semantic model without affecting teammates, and the team wants reviewers to see a line-by-line diff of every measure change in a pull request. Which combination should they use?