Source Control for Power BI (Azure DevOps, Git)
Bring real version control to Power BI: save reports as file-structured PBIP projects and sync them with Azure DevOps and Git — diffable changes, peer review, and multi-developer collaboration.
TL;DR
- Power BI now supports true source control through two features: PBIP files (file-structured Power BI Desktop projects that replace opaque binary PBIX files) and built-in Git integration. Save your report as a PBIP project, commit it to an Azure DevOps repo, and connect that repo to your Power BI workspace — and you get version history, diffable changes, peer-review check-ins, and simultaneous multi-developer work.
- You need a premium capacity (PPU, Premium, or Fabric), VS Code, a local Git install, and an Azure DevOps account tied to the same Microsoft identity.
- Keep the local repo close to the drive root — PBIP files have a character path limit.
Overview
Source control is a powerful tool for development teams — version control, qualifying deliverables via peer-review check-ins, and multiple developers working on the same project simultaneously. The benefits of incorporating it into your workflow can't be overstated.
Microsoft has launched two features that enable this for Power BI:
- Git integration with Power BI — Power BI Desktop projects Git integration and Manage a workspace with Git.
- Power BI PBIP files — Power BI Desktop projects.
The crux: you can now save binary PBIX files as file-structured PBIP files that make changes transparent and organized, and those file changes can be committed to Git and synced with your Power BI workspace.
The scope of this article is anyone looking to get Git integration quickly with Power BI, tailored for small-to-mid-size development teams.
Prerequisites
Before you begin, ensure you have the following:
- A premium capacity — Premium Per User, Premium Capacity, or a Fabric license (PBI Git prerequisites).
- Visual Studio Code — bridges your local environment with Azure DevOps (Download VS Code).
- A local Git instance — connects with Azure DevOps (Download Git).
- An Azure DevOps account — a free account associated with your Microsoft license, using the same account as your PBI access (Create Account).
Setting Up Azure DevOps
1. Create an Organization
Once you have created your account, create a new organization. To keep this cost-effective for a small-to-mid-size team, create one solution for your organization or department (subdividing by workspace later). For this demo, name the organization "AnalyticalAntsDemo".
2. Create a Project
Create a project scoped large enough that multiple projects can live here (e.g., multiple Power BI workspaces). Call it "AnalyticalAntsDemo" and set visibility to private.
3. Create a Repo
Make sure the project can create repositories: in the bottom left, click "Project settings", scroll to General > Overview, and ensure Repos is turned on under Azure DevOps services.
Now create a repo. Click Repo and "Initialize the main branch" at the bottom. Then create subfolders for your Power BI environments so you can link multiple workspaces to their own folder within the repository. Call the new folder "Workspace GITDemo" and create a new Readme file. On the next screen, select Commit (and commit again).
Your Azure DevOps repo and folder structure are now set up. Two steps remain: sync this repo with your local environment, and connect the repo to Power BI.
Setting Up Your Local Environment
From the Azure DevOps repo, select "Clone" then "Clone in VS Code". This opens VS Code and asks you to create a local folder for the repository. Keep the local repo folder close to your root directory — there is a character path limit for PBIP files (PBIP considerations and limitations). Sign in to your Microsoft account when prompted.
That is it — your local environment is done. To maximize the experience, save your PBIX files to this folder as PBIP files. When you need to make adjustments, edit the PBIP files here and then push through source control.
Checking In Via Source Control
This is a brief introduction to checking in your PBI code via source control. We will not cover branching, merging, or approvals — you can find a more detailed review in Microsoft: Share your code with Git.
Adding Changes
Save changes to the workspace folder within this repo (as a PBIP file). Then go to Visual Studio Code > Source Control, where you will see all the changes you have made, and "Stage All Changes".
Enter a message capturing the essence of the check-in — something like "User Initials – Short Description of work" — then Commit and Sync Changes.
That is it. Your online code now matches your local. You will now:
- Have a record of changes
- Have version control
- Be able to sync your Power BI workspace based on your local work
Setting Up Power BI with Git
Go to the target Power BI workspace (or create one), open Workspace settings, and connect to your new Git folder and repo. Everything is a drop-down pick-list except the Git folder — type in the workspace folder name you created earlier. Press Connect and sync.
Now your environments are tied. You can click "Source Control" anytime to sync your Power BI workspace with Git and vice versa. You can even branch from Power BI and check in to Git; any changes appear in the "Source Control" section.
Conclusion
Power BI integration with Git brings powerful improvements to your workflow, and Microsoft has made these integrations extremely accessible. If you need additional guidance on anything Power BI related, feel free to reach out.
Frequently Asked Questions
Can Power BI reports be put under source control?
Yes. Saving reports as file-structured PBIP projects instead of binary PBIX files makes changes transparent and diff-able, and those files can be committed to Git and synced with a Power BI workspace through built-in Git integration.
What do you need to use Git integration with Power BI?
A premium capacity (Premium Per User, Premium capacity, or a Fabric license), Visual Studio Code, a local Git installation, and an Azure DevOps account tied to the same Microsoft account used for Power BI. Save reports as PBIP files to make them source-controllable.
Why keep the local repo folder close to the drive root?
PBIP projects have a character path limit, so a deeply nested local folder can exceed it and break the files. Cloning the repo near the root directory keeps paths short enough for the project files to save and sync reliably.
Governance is how a platform stays yours
Source control is one piece of building data platforms a client's own team can own and operate. If you want reporting that's governed, versioned, and yours to keep, let's talk.
About the author — William Rodriguez is the founder of Analytical Ants, the delivery arm of Analytical Solutions. He spent roughly a decade architecting enterprise BI and data platforms for operations running $10M–$60B in revenue, and holds an MBA from Emory University's Goizueta Business School with dual undergraduate degrees in Finance and Managerial Science. More about Analytical Ants.