Power BI Desktop doesn’t track your changes over time. It can’t show you what’s different between versions. It doesn’t tell you who changed what. Git does all of this, but only if you set it up correctly.

This is the setup that every advanced Power BI DevOps practice assumes you already have, which is what makes everything else work. Before you use Tabular Editor. Before deployment pipelines. Before team collaboration. You need this foundation first.

This article is the detailed walkthrough to get to this setup in less than 30 minutes without the need for Git experience.

This article is also available on my Medium.com

Why Would We Need Version Control with Power BI?

Let me show you the specific problems that you may come across in this context:

Problem 1: Lost changes

You spend two hours building measures. Power BI Desktop crashes. You lose everything. Or worse, you overwrite your own work by opening an old file. There’s no way to recover because Power BI doesn’t track versions.

Problem 2: Team conflicts

Two people edit the same .pbix file. Both publish to the service. The second person overwrites the first person’s changes. Nobody realizes until users report missing features. There’s no merge capability in .pbix files.

Problem 3: No audit trail

Something breaks in production. You need to know what changed and when. The Power BI service shows you when the file was published, but not what actually changed inside it. You have no history.

Problem 4: Can’t experiment safely

You want to try a different model structure. But if it doesn’t work, you can’t easily go back. You end up keeping multiple copies of files with names like “Model_v2_final_ACTUAL_final.pbix”. This gets messy fast.

The solution

.pbip format + Git gives you version control, change tracking, team collaboration, and safety nets. This setup prevents these problems. It’s not just a nice-to-have.

First we are going to create a cloud repository and clone it to VS Code, and then we will add the project files to this repository.

Step 1: Set Up Your Git Repository

In this step, we will create a new repository and have it added to the VS Code. I’ll show you how to do this using Visual Studio Code because most Power BI developers already have it installed.

Before you start, make sure Git is installed. Open a command prompt and type git --version . If you see a version number, you’re good. If not, download Git from git-scm.com and install it with default settings.

Install Visual Studio Code if you don’t have it. Download it from https://code.visualstudio.com/download It’s free.

Connect to GitHub or Azure DevOps. We will need a remote repository hosted on platforms such as Azure DevOps or GitHub so that we can push our work to it, back up our work and share it with teammates. Right now your Git repository only exists on your computer.

If you’re using Azure DevOps: Create a new repository in your project and then click on clone in VS Code. This will open the VS Code with the repository cloned in it. You may be asked to select a folder. Make sure to create a new clean folder to avoid conflicts for now and select that folder. This folder will contain all the snapshots of your work and will be used to sync with the remote. Make sure you remember where you saved this folder as we will need it in the next step.

If you’re using GitHub: Go to github.com, create a new private repository (don’t initialize it with any files), and on VS Code press Ctrl+Shift+P and paste the repository URL in the field when prompted. You may need to log in using your GitHub credentials to be able to connect to private repositories.

Now you have the remote repository cloned in VS Code.

Step 2: Convert Your File to .pbip Format and add it to the repository folder

Start with a Power BI file you’re currently working on. If you don’t have one, create a simple model to practice with.

Open your .pbix file in Power BI Desktop.

Go to File → Options and settings → Options. In the options window, select “Preview features” on the left side. Make sure “Power BI Project (.pbip) save option” is checked. Click OK.

Now we’ll put your .pbip folder into Git source control. I’ll show you how to do this using Visual Studio Code because most Power BI developers already have it installed.

Now go to File → Save As. In the save dialog, you’ll see a dropdown for file type. Select “Power BI Project (*.pbip)”. You will need to save this project in the same folder you created in the previous step. If folder is locked and Power BI does not save in that folder, you can save it in a temporary folder and then move all of the files and folders over to the folder we used to clone the remote.

What just happened:

Instead of saving one .pbix file, Power BI created a set of files and folders in that folder. Inside that folder, you’ll see:

• A .pbip file (small file that points to the other files)
• A .SemanticModel folder (contains your semantic model)
• A .Report folder (contains your report pages)
• A .gitignore file (list of files or folders that should not be tracked — see below)

Open the .SemanticModel folder. You’ll see text files with extensions like .bim or .tmdl. These are your model definition files. You can open them in any text editor and actually read them. They describe your tables, measures, and relationships in text format.

This is the key difference: .pbix is a binary file (you can’t read it). .pbip is a folder of text files (you can read and track them).

Important: From now on, work with the .pbip file, not the old .pbix. Open the .pbip file when you want to edit your model. Power BI Desktop handles it exactly the same way.

Verify your .gitignore file. This is critical. Some files in the .pbip structure should not be tracked by Git because they change every time you open the file, even if you don’t edit anything. When you saved your file as .pbip, Power BI Desktop should have created a .gitignore file automatically. Let’s make sure it’s there.

If the .gitignore file doesn’t exist, create it. In VS Code, create a new file in the root folder and name it .gitignore. Add these two lines to it and save:

**/.pbi/localSettings.json
**/.pbi/cache.abf

Why this matters: These files change every time you open your .pbip file in Power BI Desktop, even if you don’t edit anything. Without .gitignore, Git will think you have changes when you don’t. This creates noise and makes it hard to see real changes.

Save the file. This tells Git to ignore cache files and temporary files that don’t need tracking.

At this stage you should see a view similar to this screenshot on your VS Code:

Step 3: Sync your project with the remote repository

Now we have added our project to the repository folder on our local computer. But before we push our project to the remote repository, teammates cannot access or pull the project to their computers and use it. To do so, we will create the first “commit” and then sync it with the remote repository.

A commit is like a snapshot. You just saved the current state of your entire project. You can always come back to this point later.

At this stage, on source control tab you may see something like this:

This view basically says it detected some changes on the local folder (obviously, because we added the project files and folders to it). Above the file list, there’s a text box that says “Message.” Type a meaningful message like “Initial commit – converted to .pbip format”. Then click the checkmark button above the message box. This creates your first commit.

Now we have created a commit and if you refresh the remote repository, you will see these files and folders are now added to the Azure DevOps repository, and other uses would be able to access it from that repository.

Your Daily Workflow: How to Use This

This is the most important section. Setting up Git is pointless if you don’t use it correctly every day.

When you start working:

Before opening your .pbip file, open VS Code to your project folder. In the Source Control panel, click the three dots (…) and select “Pull.” This downloads any changes that other people (or you on another computer) might have made.

This one step prevents most team collaboration problems. Always pull before you start working.

While you’re working:

Open your .pbip file in Power BI Desktop. Make your changes like normal. Add tables, create measures, build report pages. Work exactly as you always do.

When you finish a logical piece of work:

Save your file in Power BI Desktop. Then switch to VS Code. You’ll see changed files in the Source Control panel.

Look at what changed. VS Code shows you the differences. Click on any file to see what’s different from the last commit. This helps you verify you’re committing what you think you’re committing.

Write a commit message that explains what you changed. Good commit messages:

• “Added sales by region measure”
• “Fixed date table relationship”
• “Created customer demographics page”

Bad commit messages:

• “Updates”
• “Changes”
• “Fixed stuff”

The message should tell someone (including future you) what this commit does without opening the files.

Click the checkmark to commit. Then click the three dots (…) and select “Push” to send your changes to the remote repository. After push is successful, you can see the new commit is added to remote repository which is shown under graph section:

How often should you commit?

Commit after each logical change. Not every single edit, but each complete piece of work.

For example:

• You add three related measures → One commit
• You create a new report page → One commit
• You restructure a table → One commit

Don’t wait until the end of the day. Don’t commit broken work. Each commit should be a working state of your model.

Working with a team:

When multiple people work on the same model, the workflow is:

1. Pull before you start (gets their changes)
2. Do your work
3. Save in Power BI Desktop
4. Pull again (in case someone pushed while you worked)
5. If there are conflicts, resolve them (more on this below)
6. Commit your changes
7. Push to remote

Handling simple conflicts:

Sometimes Git can’t automatically merge changes. This happens when two people changed the same part of the same file.

VS Code will mark files with conflicts. Open them. You’ll see sections marked like this:

<<<<<<< HEAD
Your changes
=======
Their changes
>>>>>>> main

Decide which version to keep, or combine them manually. Remove the marker lines. Save the file. Then commit the resolution.

Most conflicts in .pbip files are easy to resolve because each measure and table is clearly defined. You can see exactly what each person changed.

Common Mistakes to Avoid

Mistake 1: Missing or deleted .gitignore file

Power BI Desktop creates a .gitignore file when you save to .pbip format. If this file gets deleted or is missing, Git will track cache files. These change every time you open the .pbip file. You’ll see “changes” even when you didn’t edit anything. This creates noise and makes it hard to see real changes.

Fix: Make sure the .gitignore file exists and contains the lines I showed earlier. If you already committed cache files by mistake, you can remove them from Git tracking while keeping the files on disk.

Mistake 2: Committing broken models

You’re halfway through a change. The model doesn’t work yet. You commit anyway “to save progress.” Later, someone else pulls your broken code.

Fix: Only commit working states. If you want to save work in progress, use Git’s “stash” feature, or create a separate branch. Keep the main branch in working condition.

Mistake 3: Pushing without pulling

You finish your work and push immediately. But someone else pushed changes while you were working. Your push fails or creates problems.

Fix: Always pull before pushing. Make it a habit. Pull → Work → Save → Pull again → Commit → Push.

Mistake 4: Vague commit messages

You write “updates” as your message. Three months later, you need to find when you added a specific measure. You can’t tell from the messages.

Fix: Write messages that explain what changed and why. Pretend you’re explaining to a teammate. Future you is a teammate.

Mistake 5: Forgetting to push

You commit locally but forget to push to the remote. Your backup exists only on your computer. If your computer fails, you lose the work.

Fix: Push after every commit. Or at least push at the end of each work session. The remote repository is your backup.

Mistake 6: Editing the same model in two places

You edit the .pbip file on your work computer and your laptop. You forget which version has which changes. You accidentally overwrite good work.

Fix: Use Git correctly. Always pull before starting. Only have one place where you actively edit. Use the remote repository as the synchronization point.

You’re Ready for the Next Steps

You now have the foundation that makes Power BI DevOps work.

With .pbip + Git in place, you can safely:

• Use Tabular Editor via XMLA endpoint (you have source control backup)
• Set up deployment pipelines (you have version history)
• Implement automated testing (you can track what to test)
• Collaborate with teammates (you can merge changes)
• Experiment without fear (you can always revert)

This setup took less than 30 minutes. It prevents countless hours of problems.

What comes next:

Now that you have source control, you can use advanced tools without risk. I will have my next article on XMLA endpoints which assumes you have this setup. If you’re planning to use Tabular Editor or other XMLA tools, I’d recommend to read my next article.

Start small:

If you’re new to Git, don’t try to learn everything at once. Just follow this daily workflow:

1. Pull before working
2. Make your changes
3. Commit with a good message
4. Push to remote

That’s it. You don’t need branches, merges, rebases, or any advanced Git features yet. Just these four steps will solve 90% of version control problems.

As you get comfortable, you’ll naturally discover more Git features. Let your needs guide your learning.