PBIP and Git in Power BI: How to Bring Version Control to Data Projects

Working with Power BI in an enterprise environment involves much more than building reports and dashboards. As soon as several developers start working on the same project, familiar challenges emerge: changes can be overwritten, previous versions can be difficult to recover, and it can be hard to understand exactly what changed between one version and the next.

A significant part of the problem comes from the traditional .pbix file format.

PBIX works well for creating, sharing and distributing Power BI reports. However, it was not designed to provide the kind of source control and collaborative development experience that software development teams are used to.

Because a PBIX file is binary, Git can detect that the file has changed, but it cannot easily show what changed inside the model or report.

With Power BI Project (PBIP), TMDL, PBIR, Git, Azure DevOps and Microsoft Fabric, this scenario changes.

Power BI Project stores report and semantic model definitions as individual files in a structured folder, making them much more suitable for source control and collaborative development. Microsoft describes PBIP as part of the developer experience for Power BI Desktop, alongside Git integration and CI/CD capabilities.

In this article, we explore what PBIP is, how it differs from PBIX, and how Git, Azure DevOps and Microsoft Fabric can be combined to create a more controlled and collaborative Power BI development workflow.

From PBIX to PBIP: a new approach to Power BI development

A .pbix file packages much of the information required to work with a Power BI report into a single file.

That is convenient for many scenarios, but it becomes a limitation when we want to introduce Git-based source control.

Imagine that a developer changes a DAX measure.

Git can tell us that the PBIX file has changed. But it cannot easily tell us:

• Which measure was modified.
• Which relationship was added.
• Which column was renamed.
• Which report element changed.
• Who made the change and why.

In a collaborative development environment, this makes it difficult to:

• Review changes before they reach production.
• Track the evolution of a Power BI solution.
• Restore previous versions.
• Work on different features in parallel.
• Resolve conflicts.
• Automate validation and deployment.

PBIP changes the unit of work.

Instead of treating the Power BI solution as a single binary file, Power BI Desktop stores report and semantic model definitions as files within a project structure.

This allows Git to manage the different components of the solution in a way that is much closer to a traditional software development project.

What is Power BI Project (PBIP)?

Power BI Project (PBIP) is a project format that stores the definitions of a Power BI report and its semantic model in a structured folder rather than keeping everything inside a single PBIX file.

A typical project structure can look like this:

MyProject/

├── MyProject.pbip

├── MyProject.SemanticModel/

│   └── definition/

├── MyProject.Report/

│   └── definition/

└── .gitignore

The .pbip file acts as an entry point to the project, while the associated folders contain the definitions of the report and semantic model.

This is what makes source control with Git much more practical.

Instead of Git simply seeing that “the Power BI file changed”, it can work with the individual definitions that make up the project.

And this is where TMDL becomes particularly important.

TMDL: making Power BI semantic models source-control friendly

Tabular Model Definition Language (TMDL) is a format for representing the definition of a Power BI semantic model.

Unlike TMSL, which represents the model in a large JSON structure, TMDL uses a more human-friendly folder and file structure. Tables, perspectives, roles and cultures can be represented separately, making the model easier to read, edit and manage through source control.

For example, a measure can be represented in a TMDL file like this:

If the measure changes, Git can identify the modification in the corresponding file.

This means that version control can move from simply tracking that Power BI changed to tracking which definition changed.

It also makes collaboration easier because developers can work with a structure that is much more transparent than a single binary file.

PBIR: bringing source control to the report layer

The same philosophy now extends beyond the semantic model.

Power BI enhanced report format (PBIR) provides a source-control-friendly format for the report layer of PBIP projects. It organizes report elements such as visuals, pages and bookmarks into individual files, making it easier to track changes and resolve merge conflicts.

This is an important evolution because effective Power BI version control cannot focus exclusively on the semantic model.

With TMDL for the semantic model and PBIR for the report, PBIP provides a more complete foundation for managing Power BI projects through source control.

In other words:

PBIP + TMDL + PBIR = a Power BI project designed with source control in mind.

PBIP vs. PBIX: when should you use each?

PBIP does not necessarily mean that PBIX disappears from every Power BI workflow.

The right format depends on the scenario.

For enterprise Power BI development, where solutions need to evolve over time and multiple people contribute to them, PBIP provides a much stronger foundation for collaboration and lifecycle management.

How to convert a PBIX project to PBIP

The first step towards adopting this approach is to save an existing Power BI project in PBIP format.

Power BI Desktop currently provides the option to save work as a Power BI Project (.pbip) through its developer-focused features. Microsoft currently marks Power BI Desktop projects as a preview feature, so the exact experience may evolve as the functionality continues to develop.

The basic process is:

1. Open the .pbix file in Power BI Desktop.
2. Go to File → Options and settings → Options.
3. Enable the relevant Power BI Project preview feature.
4. Select File → Save As.
5. Choose Power BI Project (.pbip).
6. Select the destination folder.
7. Save the project.

Power BI Desktop then creates the project structure containing the report and semantic model definitions.

If TMDL is enabled, the semantic model can be stored in the /definition folder using TMDL rather than the traditional model.bim structure. Microsoft currently documents TMDL-based PBIP storage as a preview capability.

What does the project look like?

Once the conversion is complete, the project may look similar to:

The exact structure depends on the project configuration and the formats being used.

One important advantage is that the definitions are now accessible outside Power BI Desktop. Developers can inspect and work with them using tools such as Visual Studio Code, subject to Microsoft’s guidance and the current capabilities of PBIP.

This is the point where Power BI starts to feel much more like a development project rather than an isolated report file.

Connecting PBIP to Git and Azure DevOps

Once the PBIP project has been created, the next step is to put it under source control.

For organizations already working within the Microsoft ecosystem, Azure DevOps provides a natural option for hosting the Git repository.

The basic process is:

1. Create a project in Azure DevOps.
2. Create a Git repository.
3. Clone the repository locally.
4. Store the PBIP project inside the repository.
5. Commit the project.
6. Push the changes to Azure DevOps.

Microsoft provides specific guidance for connecting Power BI Desktop projects with Azure DevOps and using a local Git repository with a remote Azure DevOps repository.

A simple repository structure could look like this:

From this point onwards, the project can be managed using standard Git workflows.

The real value: making Power BI changes traceable

This is where PBIP really demonstrates its value.

Imagine that a developer changes a DAX measure from:

With the project stored as source-control-friendly files, Git can show the difference between the two versions.

The team can identify:

• What changed.
• Who changed it.
• When it changed.
• Which file was affected.
• What the previous version looked like.

This is much more than having a backup.

Version control becomes part of the development process.

Branches and Pull Requests: Git for Power BI development

Once the project is stored in Git, development teams can apply familiar branching strategies.

For example:

The developer works on a feature branch and, when the work is ready, creates a Pull Request against main.

Another developer can review the changes before they are merged.

Instead of receiving a new .pbix and manually comparing versions, the team can review the actual changes to the project definitions.

This brings a familiar software engineering practice to Power BI:

code review for data and BI development.

Microsoft’s Azure DevOps integration is specifically designed to support collaboration between developers working on Power BI projects through a shared Git repository.

Connecting Microsoft Fabric to Git

The workflow can go one step further.

Microsoft Fabric allows workspaces to connect directly to Git repositories, including Azure DevOps repositories.

This creates a bridge between the development environment and the source-control system, allowing changes to be synchronized between the workspace and the repository.

A simplified workflow looks like this:

Power BI Desktop

↓

Feature branch

↓

Git

↓

Pull Request

↓

Validation

↓

main

↓

Microsoft Fabric

↓

Production

This is where Power BI development starts becoming lifecycle management.

The goal is no longer simply to create a report and publish it.

The goal is to manage a data solution throughout its development, review, validation and deployment lifecycle.

From Git to CI/CD

Once PBIP, Git, Azure DevOps and Fabric are connected, the next logical step is Continuous Integration and Continuous Deployment (CI/CD).

Azure DevOps can be used to create pipelines that process PBIP metadata and perform quality checks before changes are deployed to production. Microsoft documents a workflow combining Fabric Git Integration, Azure DevOps and PBIP for this purpose.

A mature workflow can therefore evolve from:

Build → Save → Publish

to:

Develop → Commit → Review → Validate → Merge → Deploy

This shift is particularly relevant for enterprise data platforms, where Power BI solutions are no longer isolated dashboards but part of a broader data and analytics architecture.

Practical considerations and limitations

PBIP and Git provide significant advantages, but adopting them does not automatically solve every development challenge.

Not every capability has the same level of maturity

Power BI Desktop projects and some related developer features are still evolving. Microsoft currently marks PBIP projects as preview, so teams should review the latest documentation before defining production architectures around specific features.

Git does not eliminate merge conflicts

Source-control-friendly files make differences easier to identify, but they do not eliminate conflicts.

This is particularly relevant when multiple developers modify the same report elements simultaneously.

A clear branching strategy and development process therefore remain essential.

External editing requires care

PBIP makes project definitions accessible outside Power BI Desktop, including through tools such as Visual Studio Code. However, Microsoft warns that modifying metadata externally can result in unexpected behaviour or inconsistencies in some scenarios.

The technology enables a more developer-oriented workflow, but governance and development standards are still essential.

PBIP + Git + Fabric: a new way to develop Power BI

Moving from PBIX to PBIP may initially look like a change of file format.

In reality, it is a change in the way Power BI solutions can be developed and managed.

PBIP structures the project. TMDL makes semantic model definitions easier to manage through source control. PBIR brings the same philosophy to the report layer. Git provides version control and collaboration. Azure DevOps introduces familiar development workflows. And Microsoft Fabric connects source control with the broader data platform.

Together, these capabilities bring Power BI closer to the development practices already established across modern software engineering.

Three ideas summarize the shift:

1. Version control matters in Power BI

When a BI solution is critical to the business, knowing what changed, who changed it and when should not be optional.

2. PBIP enables better collaboration

By storing project definitions as source-control-friendly files, teams can work with branches, commits and Pull Requests instead of passing around increasingly complex PBIX files.

3. PBIP is a foundation for CI/CD

PBIP is not the final destination. It is an important building block for a more mature Power BI development lifecycle, where validation, governance and deployment can become increasingly automated.

Ultimately, if Power BI is part of an enterprise data platform, its development lifecycle should be managed with the same discipline applied to other critical technology assets.

PBIP + Git is one of the key steps towards making that possible.

Want to discover what PBIP + Git could do for your business?

If your organization works with Power BI at enterprise scale, moving to PBIP and Git can be much more than a technical upgrade: it can help you collaborate more effectively, gain greater control over changes and build the foundation for a more agile and automated BI development lifecycle. At Bravent, we can help you understand how this approach fits into your environment, what opportunities it can unlock for your team and how to apply it to your real-world projects.

Let’s talk: info@bravent.net