Power BI Version History vs Version Control Explained - When Should You Use What? [Complete Guide]

Have you ever opened up your Power BI file and realized that you destroyed yesterday's working version? Or even worse, that someone else overwrote your file? Most Power BI developers think that they have version control down because they are saving their files in SharePoint or OneDrive. But that is not really version control, it's just the ability to time travel between your files. If you're doing proper version control, it's gonna let you compare the changes, collaborate with other team members working on the same file at the same time. And you can also roll back to specific versions or specific changes without nuking the whole report. And now with the rise of Power BI project files, Git integration, TMDL, and the Fabric workflows in general, the stake is just much higher because everything is integrated. So in this video, I'm gonna break down the difference between version history and version control and when you should use what. Because if your deployment strategy is to save your PBIX files with _final_version2_reallyfinal. pbix, then We need to talk. Enough of all this talking. You know what we like to do at Guy in a Cube. Let's head over to my laptop.

When you're working with Power BI Desktop files, so. pbix files, you have version history now built into Power BI Desktop. So if we open up the name of the report itself, you see now that we have this version history button here. You can click on that, and then you're gonna see that this is the current version. You can then decide to roll back to any previous versions. You also see who modified this file. And you can also do this from SharePoint or OneDrive directly if you want to. Now, version history also exists inside of Power BI service.

So let's take a look at that as well. Here I am inside of my sales workspace, and I have a semantic model. And if I click the ellipsis here, you do see that I have version history here, where I can take a look at different versions, and then I could also here decide to restore to a previous version of my semantic model. A big difference here is that the version history here in Power BI service is for the semantic model, not the report itself. You're allowed to save up to five versions of the semantic model. And if I open up the semantic model itself, I could then also decide to actively save this specific snapshot as a version, because maybe I'm doing some changes and I want to make sure that I can roll back. Or also here I could take a look at the previous versions that I have of this semantic model. But now we're gonna take a look at version control, what that looks like and how it's different.

Inside of my Power BI workspace here, you see that I have source control connected to it. So what I've done here is that I have, for this workspace, connected this to my Git repo, which is inside of GitHub. And that means that any changes I'm doing to, well, any of the items that I have here inside of my Fabric workspace will then be saved and stored. And now if you open up Source control here, you can see that I have already made some changes to some of my Fabric items, and my source control is keeping track of that. Telling me that, hey, I made some changes. Then I can actively decide to commit this to GitHub. So let's start by making a change to our sales analytics semantic model

and see how that looks like with this Git integration and version control. So here you see I have my semantic model, and I have a couple of measures here. For instance, percentage of company revenue here. Now, this measure is used inside of my executive dashboard report right here. So you see the percentage of the company revenue for the different stores as part of the store performance indicator. Now, let's say that I made a change to my semantic model. I just deleted or changed part of my DAX measure, and this was saved. Now if I go back to my workspace now and open up source control, we see here that the Git integration is able to identify that I did make now a new change on the sales analytics semantic model, and I can actually review the changes that were made. I can then actively go through the TMDL code of my semantic model and see that, ah, the measure, okay, I changed my measure and removed all stores, so this line changed. Now this change is messing up my report because if we go back to the executive dashboard report and we just refresh this, we're now seeing that the percentage of the company revenue for the different stores is 100% for everything because the filter is not working properly. So this messed up my report now, and I want to go back to my previous version. With source control here, I could then decide to, for the semantic model, the one that I did changes to, I could decide to undo this actively here. Say that, mm-mm, I don't want this. So I go back to the previous version. Okay, so now it says that the changes were undone. Let's go then back to the report then, and if we refresh this report, ta-da. It worked just like that. So now we obviously made some changes to the semantic model. But what if I change something in the report itself? So let's try and do that. Let's say that we're changing up something here with the revenue by region. Let's just change this to a different visual, and let's just save this report and go back to the workspace. Now let's see if the source control detects that we'd made a change to the report. And yes, you see here now that executive dashboard is now something that we did modify, and also here we can actually review the changes of the report itself in the same way. So here you see that we changed from a clustered bar chart to a percent stacked column chart. That was exactly what we did. I could then decide to commit this or undo. And now what if we have two people in our team working on the same report or semantic model at the same time making changes? How does version control solve that?

Well, it solves that by branching out. So now I can take that report and the semantic model into my own little branch, my own safe environment, and I can make the changes and development that I want. And then at the same time, someone else from my team can also do that. They can take the same report, the same semantic model, and also do development at the same time, make their changes in their secure branch. Then when we're committing our changes back to the main branch, we can see

all the lines that I've changed. We're gonna see that there are no merge conflicts, meaning that we didn't change the same things. So we can just merge this all together in a beautiful model or report. If, however, we did end up making changes to the same visual in the same report, and we try to commit back to the main branch, and we have a merge conflict, we can then because of the TMDL, see then exactly, okay, what changed? What did you do? What did I do? And then we can make an informed choice on what we want to do and move on with. That was a lot of things, but now we know the difference between version history and version control. Okay, awesome. But when should you use what? Well, I have five checks that you could go through to decide what would work best for you.

First up is team concurrency. Is it one person making most of the changes? Then version history is the way to go. If you have multiple developers making changes at the same time, then you would need Git integration. Second up is change visibility. Do you only have the need to roll back to the previous version of a file? Cool. Then version history is enough. But if you need to know exactly what changed, then you would need the Git integration. Third is release discipline. Do you have an informal publishing rhythm? Cool. Version history is enough for you. If you need branch policies or approvals, then you would need the Git integration. Fourth up is governance. Do you only require a light governance setup? Cool. Version history is also the way to go. But if you're working in regulated environments, the Git workflow will provide you with pull requests and evidence in just overall a safer architecture. Last point, platform scalability. If you're working in a small creator-led team or you're doing prototyping and checking things out, version history, that's enough. But if you're working with multiple teams and you're doing cross-team semantic modeling or report development, then Git becomes the foundation you need to build on. I hope it was helpful. Did you learn anything? If so, let me know what in the comments below. Remember to hit the subscribe button to check out all the other awesome videos from Adam, Patrick, and this gal right here. And I am really excited to see you guys in the next video. Bye.