GitHub Version Control for Power BI

Version Control – it is an important part of a standard development process, one that typically becomes more complex as fusion development concurs.

When it comes to Power BI, the typical Development lifecycle may look something like this:

While this cycle may only have one full rotation, it is often that it is an evolving process that requires multiple iterations as client requirements evolve. Because of this, it is important to have a Version Control System in place. There are a few different ways one could go about this (including utilizing Fabric) but one tool that is quite common across teams for their standard development process can also be used for Power BI development – GitHub.

GitHub has MANY practical use cases, including repository management for code and education, extensions, and projects for teams.

Before we get into how to utilize GitHub for Power BI Version Control there are a few prerequisites…

Software and Prerequisites for GitHub X Power BI Version Control

  1. Create a GitHub Account if you do not already have one
  2. Download Git for Desktop
    • Link Git Desktop to your GitHub Account
  3. Ensure that you have Power BI Desktop installed and the preview feature for .PBIP projects enabled
    • NOTE: To turn on this preview feature, open your Power BI Report in Power BI Desktop, then do the following:
      • File > Options and Settings > Preview Features > Power BI Project (.PBIP) Save Option
    • NOTE: This feature is in preview as of the time of blog publication. It is subject to change and have continuous updates. Read more here.

How to use Power BI Projects

Once you have all prerequisite to do’s complete, it is time to develop a Power BI Report. As far as report creation and development, this process will not change. However, the difference comes when it is time to save your work. Rather than just saving your file as a standard .PBIX we will instead save it as a .PBIP. To do this hit the drop down from your save dialog box and change the file type to .PBIP. (img 1)

When saving a .PBIP file I recommend saving to its own project folder. Because when you save as a .PBIP, your project gets broken into 3 different parts (img 2):

img 2
  • Power BI Report Project File
    • This will act as your working document, and it is the file you will chose as you continue development and modification of your report.
  • Report Folder/File
    • This folder is created and holds the coded blueprint for how your report is to function and act. It will contain the code for layout, settings, and features you embed within your report.
  • Semantic Model Folder/File
    • This folder is created and holds the coded blueprint for your semantic model behaves. Here you will find DAX queries, .JSON files, and most importantly a .BIM file which if opened in something such as VS Code will show you the hard coded details of your semantic model.

NOTE: When saved as a project, you’re not forced into making changes to your semantic model and report definitions only in Power BI Desktop. You can use other tools such as VS Code, open-source community tools like Tabular Editor, or even Notepad. However, not every file or change supports editing by external, open-source tools.

Once saved, we can then begin to think about Version Control.

Using GitHub for Version Control

In GitHub Desktop, first we will create a new repository. To do this, hit file > Create new repository. Besure to change the local file path to the folder we created earlier when saving our .PBIP file (img 3).

img 3

From here a repository is created.

img 4

When looking at a repository on GitHub Desktop, there are a few areas I would like to call out (img 4):

  • Changes
    • The changes tab (on the left side navigation box) will show you all changes that have been made once they have been committed to the branch.
  • History
    • History will show you each change made to your project, in code.
  • “Publish Repository”
    • The Publish Repository Button is critical as it what will allow your changes to be viewed in GitHub Online. This is important for fusion development teams and collaboration.

Next you will want to hit “Publish Repository”. Once you do this a dialog box (img 5) will appear where you can enter a name and description. Once you do this and hit “Publish Repository”, you will notice that in the background tab GitHub Desktop is working to push the Repository to GitHub Online. Once it is complete the dialog box will close, and you will be able to open the file on GitHub Online.

Img 5

Once your repository is published you can view it on GitHub Online. You can do so by going to GitHub.com or hitting the “View in GitHub” button directly from Git Desktop (img 6).

img 6

Once in GitHub you can see all attributes of your project. This will show your first Commit, or Version of your Power BI Project (img 7).

img 7

Making Changes to your PBIP File and Committing to GitHub

When making iterations to your Power BI Project, make sure to use the existing .PBIP file. In this example, the iterations I have made would be adding a slicer to my report as well as a new measure.

Once I am happy with my changes in my .PBIP file, I will save it.

Then let’s return back to Git Desktop. As you can see, (img 8) both changes I made were detected once I saved my file. This is where file types become an important observation.

The first change I made was adding a slicer, because this was attached to the report folder, we can assume the .JSON change is going to be linked to cosmetic changes. The .BIM change is related to the creation of a new measure and stored in the semantic model folder (img 8).

img 8

Before committing these changes to main (Your GitHub Online Branch) I recommend giving a Summary and Description of the change (img 9). This will help if you ever need to review changes or are working collaboratively with a team. Once done, hit “Commit to main”.

img 9

NOTE: Be aware of the checkboxes. If both changes are checked, and you commit to main it will commit both with the same summary and description. If you do this accidentally, an undo button appears under the “Commit to main” button. Then you can try again.

Once you have committed all changes you are then able to push this to GitHub Online, which will update the Version of the project. To do this ensure that there are no more pending changes and then hit “Push origin” button on the right (img 10).

img 10

Now if you go back into GitHub Online you will be able to see the most recent changes and when they were updated (img 11).

img 11

Reverting Changes

Say accidently a file was deleted or something in your model went drastically wrong. In this example, say someone accidently deleted my .pbip file and committed that change to GitHub Online.

Upon refreshing GitHub Online, you will see that my .pbip file is no longer available (img 12). This is also true for the local file. At this point, it would appear that my hard work is gone. However, with the power of version control, I can actually go backwards in time.

img 12

To revert changes you will go into Git Desktop and then go to the History Tab. Here you will see every single change that has been committed.

To revert a committed change, right click on the step you wish to revert and hit “Revert Changes in Commit” (img 13)

img 13

Once reverted, you will want to repush to origin, and this will enable you to see the file both locally and in GitHub Online (with all most recent commit status’)(img 14).

img 14

It is important to note that the Power BI Service does not accept .PBIP files directly. Once your report development is completed and ready for handoff to the client, you must convert your .PBIP file to a .PBIX file using the “Save As” option in Power BI Desktop. This conversion ensures compatibility with the Power BI Service for deployment and sharing. While .PBIX and .PBIP files can be converted back and forth seamlessly, always be mindful of which file type you are working with. Observing which file, you open and save will help maintain the integrity and structure of your report throughout the development and deployment process.

In conclusion, version control in Power BI is vital for maintaining control over report development, ensuring quality, and fostering collaboration among team members. By implementing robust version control practices, organizations can enhance their Power BI projects’ efficiency, reliability, and security, ultimately delivering better insights and value to stakeholders. Whether you’re working in a small team or a large enterprise, adopting version control will empower you to manage your Power BI reports and datasets effectively.

Want to learn more about how Power BI can be integrated with GitHub to help DevOps Process? Watch for a blog post from Marcel Chabot on GitHub CI Reporting using Power BI – Posting Aug 30th, 2024. (Once date is passed, I will link directly to the blog post). Or check out his latest Blog post about Business Central DevOps leveraging GitHub.

Thanks!

#CommunityRocks

3 responses to “GitHub Version Control for Power BI”

  1. […] *Related blogs: GitHub version control for Power BI – not a pickle […]

  2. […] *Relevant Blog: GitHub Version Control for Power BI – Not a Pickle […]

  3. […] Source Control Integration: Ideal for developers working in teams, as it allows files to be managed with tools like Git (see my post on this!). […]

Leave a Reply to MVP’s Favorite Content: Power BI, Microsoft Fabric, Azure | Telkom UniversityCancel reply

I’m Sav

Welcome to Not a Pickle Blog, a technical resource focused on Power BI and Microsoft Dynamics 365 Business Central. I’m Savannah, and this blog is dedicated to translating complex data models, APIs, and business processes into practical, actionable insights. You’ll find deep dives into reporting patterns, real-world Business Central scenarios, Power BI best practices, and lessons learned from hands-on experience. The goal is simple: build reliable reports, understand your data, and make it work for your business.

Let’s connect

Discover more from

Subscribe now to keep reading and get access to the full archive.

Continue reading