Git for Power BI and Fabric Users: A Beginner's Guide

Visual Studio Code is where you will do all your day-to-day Git work. Git support is built in; no extension is required.

VS Code can open individual files, but its real strength is working with folders. When you open a folder, VS Code treats it as a project: the file explorer shows the full tree, the terminal opens at the root, and Git tracks everything inside it as a single workspace. A .pbip project is a folder, so this maps directly: open the SalesReport/ folder in VS Code and you have your entire report and semantic model in one place.

Download and install Git for Windows. Accept the default settings throughout; you do not need to change anything. Git runs quietly in the background. It is the engine every other tool in this list relies on; nothing else works without it.

GitHub is the recommended starting point. It is the most widely used platform, free for private repositories, and straightforward for personal projects or small teams. VS Code opens a browser sign-in window the first time you connect, so setup takes under a minute.

Azure DevOps Repos is the enterprise standard for Microsoft-stack teams. If your organisation uses Azure DevOps for work items or pipelines, your Git repositories belong there too. Fabric workspaces can connect to Azure DevOps repos for Git integration when a Fabric capacity and tenant admin enablement are in place — which makes it the natural choice for corporate BI teams. In most organisations it is already licensed and provisioned.

GitLab and Bitbucket are solid alternatives in organisations that prefer self-hosted infrastructure. The Git concepts are identical across all platforms; only the interface differs.

Git attaches your name and email to every commit you make. You only need to do this once per machine. Open VS Code’s integrated terminal with Ctrl+` and run these two commands:

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

These are the only two terminal commands in the entire setup. Paste them exactly after replacing the name and email, then close the terminal — everything else in this guide uses VS Code’s visual interface.

After that, every commit on that machine will carry your identity automatically.

Git is a version control system. At its core, it records snapshots of your project files over time. Every time you save a snapshot (called a commit), Git stores what changed, who changed it, and a short message explaining why. You can return to any earlier snapshot at any time.

Think of it as a time machine for your project folder. The folder looks exactly the same on your machine; Git manages the history quietly in the background.

What Git is not

Git is not GitHub. This is the most common point of confusion. Git is the tool that runs on your machine and tracks changes. GitHub is a website that hosts Git repositories in the cloud so teams can share them. The two are separate; you can use Git without GitHub entirely.

Git is also not OneDrive or SharePoint. Those tools sync files automatically in the background. Git requires you to decide what to save and when. That deliberate choice is what makes it powerful. A sync tool records every keystroke; Git records decisions.

Git is not only for software developers. Power BI analysts, Fabric engineers, data engineers, and report authors all benefit. If you edit files and work with other people, Git applies to you.

A repository (repo) is the folder Git is tracking. Everything inside it can be versioned. When you initialise Git in a folder, it starts watching that folder and all its contents.

Initializing a repository

You initialise a repository once. In VS Code, open the project folder and click Initialise Repository in the Source Control panel (Ctrl+Shift+G). Git creates a hidden .git folder at the root. That folder is the repository; do not delete or move it.

The .gitignore file

When you initialise a repository, VS Code will offer to create a .gitignore file. Accept it. A .gitignore tells Git which files to skip entirely: cache files, local settings, and temporary outputs that should never be committed or shared. For PBIP projects the defaults already cover the important cases (cache.abf, localSettings.json), but you can add anything else your team agrees should stay out of version control.

Before you can commit, you need to understand one concept that surprises almost everyone coming from SharePoint or OneDrive: staging.

When you save a file in OneDrive, it syncs immediately and automatically. Git works differently. Saving a file just changes it on disk; Git does not record anything yet. To commit, you first stage the files you want to include in the snapshot. Staging is your chance to say “these specific changes belong together” before committing them as a single, described unit.

Git sees your project in three zones at all times:

A practical example: you updated a Margin % measure and also changed a page title, but the title change is not ready yet. Stage only the measure file, commit it with the message Add Margin % measure, and leave the title change in your working directory for the next commit. The staging area is what makes this precision possible.

A commit is a snapshot of everything in the staging area at the moment you commit. Git attaches your name, a timestamp, and a message explaining why the change was made. You can return to any commit at any time.

In VS Code, the staging area lives in the Source Control panel (Ctrl+Shift+G). Files with unsaved changes appear under Changes. Click the + next to a file to move it to Staged Changes, type a message in the box at the top, and press Ctrl+Enter to commit. Every commit gets a unique ID (a hash like a3f9c2d) that Git uses to identify that snapshot internally.

A branch is an independent line of work. Changes on a branch do not affect your main code until you deliberately merge them. For Power BI and Fabric developers, this means one person can build a new measure group while another redesigns the executive page or modifies a pipeline; both lines of work proceed in parallel, on the same project, without either person overwriting the other.

Name branches clearly: feature/margin-measures beats test1 every time.

Every developer keeps a full copy of the repository on their own machine — that is the local repository. The remote is the cloud copy hosted on GitHub or Azure DevOps. It is the shared version everyone synchronises with. After committing locally, you push your changes to the remote; your teammates pull from it to get your latest work.

What are remotes

A remote is simply a named URL pointing to a repository hosted on another server. When you clone a repository, Git automatically creates a remote called origin pointing back to the source. Most teams work with one remote. When VS Code shows ↑1 in the status bar, it means you have one local commit ready to push to origin.

Checking out a branch means switching your working environment to that branch. When you do it, VS Code updates all your open files to reflect the state of that branch. Changes you made on another branch disappear from view; they are safe on their own branch, just not visible until you switch back.

The current branch is always shown in the bottom-left status bar in VS Code. Click it to open the branch picker, select a branch, and VS Code switches instantly. To create a new branch and switch to it in the same step, type a new name in the picker and choose Create new branch.

Does Git lock files?

No. This surprises many people coming from SharePoint, SVN, or Perforce, where “checking out” a file locks it so nobody else can edit it. Git works completely differently.

Two people can edit the same file at the same time. Git sorts it out at merge time, not before.

When a feature branch is ready, you bring it into main — the shared, stable version of the project — through merging. Git compares both branches and combines the changes. If two people edited different files, the merge is automatic. If they edited the same lines of the same file, Git flags a conflict for you to resolve manually before the merge completes.

On a shared team repo, the standard path is a pull request (PR): a proposal to merge your branch, made through GitHub or Azure DevOps. Opening a PR lets reviewers see the exact diff, leave comments, and approve before anything reaches main. On a solo project you can merge directly in VS Code. Who reviews a PR on a BI team? Typically another report developer, the semantic model owner, a tech lead, or the workspace owner.

When in doubt on a shared repo, open a PR. It takes thirty seconds and gives everyone visibility.

Before branching, always click the sync arrows (↓) in the VS Code status bar to pull the latest main. This ensures your new branch starts from your teammates’ most recent work, not a version that is already behind.

Say you need to add a new Margin % measure. In VS Code, click the branch name in the bottom-left corner and select Create new branch. Name it feature/margin-measures. You are now working in isolation; the main branch is untouched.

There are two valid ways to make the actual change. Use the one that fits the work.

Power BI Desktop path: open the .pbip project in Power BI Desktop, make the report or model change visually, and save in Desktop. This is the natural path for most report authors.

VS Code path: edit the PBIP text files directly, or use an LLM/MCP-assisted workflow that edits those files for you. This is useful when you are comfortable reviewing text changes, generating measures, or applying structured edits.

Either way, once the file is saved, VS Code’s Source Control icon shows a badge and the changed files appear under Changes. Review the diff before you stage anything.

Stage the files that belong in this specific change. In VS Code’s Source Control panel, click the + next to the changed file to move it from Changes to Staged Changes.

Staging does not change the file. It only marks it for the next commit. If you changed a Margin % measure and also experimented with a page title, you can stage only the measure and leave the title unstaged for later.

Type a descriptive message in the Source Control message box and press Ctrl+Enter. For the Margin % example, use something like:

Add Margin % measure to Sales table

After committing, your work exists in Git history, but only on your machine. Nobody else has it yet.

Push publishes your local commit to the cloud repository. Use the sync arrows or the Publish Branch button in VS Code. The up arrow (↑) means you have local commits waiting to push; the down arrow (↓) means teammates have pushed commits you have not pulled yet.

When the work is ready, the next step depends on whether this is a personal project or a shared team repo.

Solo or personal repo: Click the branch name in the VS Code status bar, switch back to main, open the ... menu, select Branch → Merge Branch, and choose feature/margin-measures. Your measure is now part of main.

Shared team repo: Push the branch and open a PR. A teammate can review the diff and approve before anything touches main.

After the PR is approved, merge it into main. Your Margin % measure is now part of the shared, stable version of the project.

For the next change, pull main, create a new branch, and repeat the loop.

A merge conflict happens when two people edit the same lines of the same file and Git cannot decide which version to keep. For .pbip projects, this most often happens in model definition files when two people modify the same table or measure at the same time. In Fabric, the same applies to shared semantic models or notebooks. Because both formats store content as readable text, Git can show you exactly where the disagreement is.

A merge conflict is not a failure. It is Git doing its job, flagging a decision that requires a human. The fewer lines each commit touches, the less often conflicts appear.

If two people never edit the same file at the same time, merge conflicts are rare.