Get Your Power BI Reports AI-Ready with GitHub

Why a repository makes AI safe to try

You might let an AI tool change a Power BI report if you could see exactly what it changed, and take the change back when it got something wrong. A Git repository gives you both, for every change, whoever makes it.

Git is a tool that records versions of a folder of files. A repository is that folder plus its full history. Each saved version is a commit: a set of changes with a short message and the name of the person who made them. GitHub is a service that hosts repositories online, so several people can work on the same one. Azure DevOps and Atlassian’s Bitbucket do the same job, and all three are built on Git, so what follows carries over to them.

For a Power BI report, that means every change is a commit with an author and a date. Before you accept a change, you see the lines it added in green and the lines it removed in red, and you can undo any change later, even one that’s already been merged. Teammates, and an AI tool, can each work on a branch of their own until their change is reviewed and merged. If you’re not ready for a repository yet, Easy Version History Comes to Power BI Desktop covers the version history Desktop keeps for a .pbix saved to OneDrive or SharePoint.

Git compares text, so all of this depends on the report being text. Power BI as Code covers saving a report as a Power BI project (PBIP), which turns its pages, visuals, and model into folders of JSON and TMDL files. This article starts from that kind of project and follows one change all the way through: a new measure, Total Sales East, added on a branch, reviewed as a diff, merged, and then undone.

1:51Three tools, set up once

You need three things, and all of them are free.

• Visual Studio Code, Microsoft’s open-source code editor. It’s where you’ll see the project’s files and commit your changes, and later where you’ll run AI tools. Download it from code.visualstudio.com, or get it from the Microsoft Store or your company’s software portal.
• Git, from git-scm.com (on Windows, that’s Git for Windows). It does the versioning, and it syncs your local copy of a repository with the copy on GitHub.
• A GitHub account, from github.com, or one your company gives you.

The video signs VS Code into GitHub the first time it opens 4:49. That step is optional. Git asks you to sign in separately, in the browser, the first time you clone or push a private repository. Git for Windows includes Git Credential Manager, which stores that sign-in so Git doesn’t ask again.

Next, tell Git who you are. In VS Code, open a terminal (Terminal > New Terminal) and run these two commands with your own name and email 6:02:

git config --global user.name "Your Name"
git config --global user.email "[email protected]"

Every commit you make carries this name and email, and that’s how the history shows who made each change. If you’d rather not publish your personal email address in a repository’s history, GitHub gives every account a private noreply address, in the form [email protected]. You’ll find yours under the email settings of your GitHub account. Use it in the second command.

One more setting is worth making before your first commit. Power BI Desktop writes Windows line endings (CRLF), and Microsoft recommends configuring Git to handle line endings so they don’t cause problems in your diffs. GitHub’s recommendation for Windows is one command:

git config --global core.autocrlf true

7:02Create the repository and clone it

On github.com, create a new repository. The video names it Sales-Demo. Repository names can’t contain spaces: type Sales Demo and GitHub turns it into Sales-Demo. Add a description if you like, and change the visibility from Public, the default, to Private, so only you and the people you invite can see it.

Creating the Sales-Demo repository. Private keeps it visible only to you and the people you invite.

Turn on Add README. GitHub creates the repository with a one-file first commit, so there’s a main branch to clone. The no-spaces rules come from GitHub, for repository names, and from Git itself, for branch names.

Leave Add .gitignore set to none. A .gitignore file lists files Git should leave out of commits, and Power BI Desktop writes its own when you save a project, but only when the folder, or the Git repository it sits in, doesn’t already have one. If you pick a template here, Desktop won’t write its file, and unless the template happens to include Desktop’s two rules, your data cache goes into the first commit. If you already have a .gitignore, add the two rules from the next section to it yourself. The video skips the license as well, since this is a report in a private repository.

Select Create repository. Then clone it, which copies the repository to your machine 9:50:

1. On the repository page, select Code and copy the HTTPS URL.
2. In VS Code, open the Source Control view and select Clone Repository.
3. Paste the URL and press Enter.
4. Pick the parent folder. VS Code creates a Sales-Demo folder inside it and offers to open it. When it asks whether you trust the authors of the files, say yes; you’re the author.

Put the repository somewhere local that nothing else syncs, so Git is the only thing managing it. The video uses C:\Projects. Avoid OneDrive and other synced folders: Microsoft notes that saving a project into a locally synced OneDrive folder can cause syncing issues that make saves fail. Keep the path short, too. Windows limits file paths to 260 characters by default, and a project nests several folders deep, so C:\Projects\Sales-Demo is a good shape.

12:00Put the project in the repository

If your report is a .pbix, open it in Power BI Desktop and go to File > Save as > Browse this device. Navigate into the cloned folder, set “Save as type” to “Power BI project files (*.pbip)”, and save. If your report is already a project, copy all of its files into the cloned folder, including its .gitignore.

The folder now looks like this:

Sales-Demo/
├── Sales Demo.Report/
├── Sales Demo.SemanticModel/
├── .gitignore
├── README.md
└── Sales Demo.pbip

There’s also a hidden .git folder, where Git keeps the history. Leave it alone.

The .gitignore, and why the cache stays out

Desktop’s .gitignore has two lines 12:47:

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

localSettings.json holds settings for your user and computer only. cache.abf is, in Microsoft’s words, “a local cached copy of the model and data when it was last edited”. There are three reasons to keep it out. It’s binary, so a diff can’t show you anything useful about it. It’s large. And it holds your data, while a code repository is for the report’s definition. Desktop opens a project without it: you get the full report and model with no data, and a refresh loads it.

What the first commit holds. Only the two files the .gitignore names stay on your machine.

The video doesn’t mention a few files that do get committed. If you save Power Query edits with Apply later, Desktop writes them to .pbi/unappliedChanges.json, and Git commits that file by default. That lets you back up unfinished query work on a branch. If you’d rather teammates never see it, add **/.pbi/unappliedChanges.json to the .gitignore. Saved tabs in DAX query view and TMDL view are committed too, as files in the semantic model’s DAXQueries and TMDLScripts folders.

To be certain the cache is excluded before you commit, run this in the terminal from the repository folder:

git check-ignore -v "Sales Demo.SemanticModel/.pbi/cache.abf"

Git prints the .gitignore rule that matches the file. No output means the file isn’t ignored.

14:08Commit and push

The Source Control view now counts every file Git sees as new: 44 in the video.

After saving the project into the clone: 44 new files waiting for the first commit, and no cache.abf among them.

Type a short commit message (the video uses “Instantiating repo”) and select Commit. Because nothing is staged yet, VS Code asks whether to stage all your changes and commit them directly. Staging picks which changes go into the next commit, and committing records them. The video answers Always, which stages everything on every commit from then on. If you want to choose files one at a time, stage them yourself with the plus icon next to each file.

A commit stays on your machine until you push it. Select Sync Changes: VS Code pulls anything new from GitHub, then pushes your commits. Refresh the repository page on GitHub and the project’s files are there, next to the README.

16:00One change, from branch to merge

Say someone asks for a new measure: total sales for customers in the East region. The change goes through six steps before it reaches main.

The lifecycle this section follows, and the way back that the next section covers.

Make a branch

A branch is a separate line of commits that starts from main. You work on the branch, and main stays as it is until you merge.

The video creates the branch on GitHub. Open the branch menu at the top left of the repository page (it shows main), type a name, and select Create branch … from main. Git doesn’t allow spaces in branch names; the video’s branch is AddTotalSalesEast.

Back in VS Code, select the branch name in the bottom-left corner of the window. The list shows your local branches and the ones on GitHub, which start with origin/. origin is the name Git gives the repository you cloned from, so origin/AddTotalSalesEast is the branch on GitHub. Pick it, and VS Code creates a local branch that follows it. You can also create the branch in VS Code, from Create new branch in the same list; it goes up to GitHub the first time you sync.

Switching branches changes the files on disk. The video closes Desktop before switching and reopens the project afterwards, which is the safe habit. If you’ve turned on the “Detect and reload external PBIP changes” preview, Desktop offers to apply the changed files instead; see what you can edit outside Desktop for how that works.

Add the measure and read the diff

Open Sales Demo.pbip, right-click the Sales table, select New measure, and enter 17:56:

Total Sales East =
CALCULATE(
    [Total Sales],
    'Customer'[Region] = "East"
)

Save the project. In VS Code, Source Control now lists one changed file, Sales.tmdl, the file that defines the Sales table and its measures. Select it to open a side-by-side diff of the last committed version against the version on disk.

One changed file. The green block is the new measure, exactly as Desktop wrote it.

Green lines were added and red lines removed; a changed line shows as both. This change only adds lines, and here they are:

	measure 'Total Sales East' =
			
			CALCULATE(
				[Total Sales],
				'Customer'[Region] = "East"
			)
		formatString: \$#,0.###############;(\$#,0.###############);\$#,0.###############
		displayFolder: KPIs
		lineageTag: d9a87150-464b-4161-9d38-2b34695a17b4

		annotation PBI_FormatHint = {"currencyCulture":"en-US"}

Now read it the way a reviewer would, next to the Total Sales measure higher up in the same file:

	/// Total sales revenue in filter context. Aggregates Sales[Total Amount].
	measure 'Total Sales' = SUM ( 'Sales'[Total Amount] )
		formatString: "$"#,0.00
		displayFolder: KPIs
		lineageTag: 2247408f-cf0d-5824-9116-4c10006ebed2

The new measure differs from its neighbours in two ways. Every other measure in the Sales table has a description, the /// line above it, and the new one doesn’t. And its format string allows up to 15 decimal places where its neighbours use two. Neither breaks the report, and both are easy to fix on the branch before merging: set the description and format in Desktop, save, and commit again. This is the same review you’d give an AI tool’s change.

Commit, push, and merge the pull request

Commit with a message such as “Added Total Sales East” and select Sync Changes 20:08. On GitHub, a banner offers to compare the branch you just pushed.

GitHub notices the pushed branch and offers to open a pull request.

A pull request asks to bring one branch’s commits into another, here AddTotalSalesEast into main, and it’s where a reviewer reads the diff before anything lands. Select Compare & pull request, give it a title and a description (the video’s says “Added DAX measure total sales east”), and select Create pull request. GitHub checks whether the branch merges cleanly into main. Select Merge pull request, then Confirm merge.

To see the result, open the Code tab, go through Sales Demo.SemanticModel, definition, and tables to Sales.tmdl, and select History.

The history of Sales.tmdl after the merge. Each commit carries its author and opens its own diff.

Last, bring the merge back to your machine. In VS Code, switch to main and select Sync Changes, so the next branch you make starts from the version with the new measure.

Undo a change

A repository’s promise is that you can take a change back, and the video stops before showing it. Which undo to use depends on how far the change has travelled.

You haven’t committed it yet. In Source Control, select Discard Changes (the curved arrow) on the file. Git restores the last committed version. There’s no copy in the Recycle Bin afterwards, so be sure. Then reopen the project in Desktop, or apply the external changes, because a Desktop session that still holds the measure writes it back the next time you save.

You’ve committed it, but haven’t pushed. Open the … menu at the top of Source Control and select Commit > Undo Last Commit. The commit disappears from your branch, and its changes come back staged, so you can fix them and commit again. Don’t use this on a commit you’ve already pushed.

It’s been merged. On GitHub, open the Pull requests tab, find the merged pull request (it’s under Closed), and select Revert near the bottom. GitHub opens a new pull request that reverses the original merge. Merge that one, and main is back to where it was, with both the change and its reversal in the history. You need write access to the repository for the Revert button to appear. Then switch to main in VS Code, sync, and reopen the project.

21:59Let an AI tool run the commands

Every click in this article has a Git command behind it. Here’s the branch-to-push part of the lifecycle as commands you could type:

git switch -c AddTotalSalesEast
git add -A
git commit -m "Added Total Sales East"
git push -u origin AddTotalSalesEast

git switch -c creates the branch on your machine and switches to it, and push -u publishes it to GitHub. To undo a commit that’s already shared, git revert followed by the commit’s ID creates the reversing commit. GitHub’s own command-line tool, GitHub CLI, is a separate install that covers the GitHub side: gh pr create opens the pull request from the terminal.

These are the commands an AI tool runs in your terminal when you ask it to do the work, and as the video puts it, you don’t have to run them yourself. Claude Code for Power BI development shows one way to set that up. Your part doesn’t change: read the diff and the pull request before you merge, and revert when it got something wrong. VS Code can also draft a commit message for you from the staged changes, with the sparkle icon in the message box. Read it before you commit, the same as any other change.

Put the project in a repository before you let an AI tool change it. Then every change it makes arrives as a commit you can read, and one you can revert. The Power BI Modeling MCP server article follows an agent’s changes to a model through to that review. The Tabular Editor CLI article reviews an agent’s command-line changes the same way.