~30 min read

Git for Power BI

Version control fundamentals for Microsoft Fabric and Power BI developers

Version Control • Branching • Collaboration • Developer Mode

Scroll to explore

Git

What version control is and why it matters

Overview

Git is the version control system used across the software industry. In this section, you'll learn what Git does, why it matters, and how it helps teams track changes, collaborate, and recover from mistakes.

What is Git

Git is a distributed version control system, meaning we always work on a local copy. It tracks every change to your files, letting teams collaborate, revert mistakes, and maintain a complete history of their work.

Git Basics

Core commands for git

Overview

This section covers the core building blocks of Git. We will look at the basic concepts of commits, repositories, and merges. These are concepts you'll use in every project to save your work, organize your history, and bring changes together.

Commits

A commit is a snapshot of your project at a point in time. Think of it like a save. Each one records exactly what changed, who changed it, and why, building a complete timeline of your work.

Key Concepts
Commit
What A saved snapshot
Contains Changes + message
Think of it as A save point
Repository
What Your project folder
Contains Files + full history
Think of it as A shared drive with memory
Merge
What Combining work
Contains Changes from two branches
Think of it as Bringing work together

Branching

Parallel workstreams and safe experimentation

Overview

In this section, we will review branching. Branching is how to work on features in parallel, while different teams manage different tasks, and keep your main project stable until changes are ready to merge.

What is a Branch

A branch is an independent copy of your codebase. You can add features or fix bugs in isolation, without affecting the main project until you're ready to merge.

Branching Workflow

After we branch, we want to copy to our local machine. Branching lets multiple developers work on different features at the same time, then merge their changes back together when ready.

Sync = Pull + Push. Most Git tools (VS Code, GitHub Desktop, Azure DevOps) offer a single "Sync" button that first pulls the latest remote changes, then pushes your local commits. This keeps both sides aligned with one action.
Branch Strategy

A branch strategy defines how your team organizes branches.

Main Branch

The single source of truth. Always stable, always deployable. All work merges back here.

Branches

Short-lived branches for each piece of work. This can be things like hotfix branches to fix bugs, or feature branches to add changes. Create one, make your changes, merge it back, delete it.

Best Practices

Try not to commit directly to main. Always branch, review, write detailed commit messages, and merge through a pull request.

Common Strategies

There are many branch strategies that vary in complexity. Below are two of the more common.

GitHub Flow
How Simple strategy for small teams
Branches Main is permanent, with temporary feature branches for each piece of work
Best for Most teams, continuous delivery
MAIN FEATURE
Git Flow
How More advanced for bigger teams
Branches Main & Develop are permanent, with temporary branches hotfix, release, and feature
Best for Large teams, scheduled releases
MAIN HOTFIX/* RELEASE/* DEVELOP FEATURE/*
Our recommendation: Start with GitHub Flow. It is simple, well-documented, and works for most Power BI and Fabric teams. Only adopt Git Flow if you need formal release cycles.

Git Overview

Key terms and concepts for working with Git

Overview

This section walks through key Git terminology and concepts, from repositories and commits to branching, pull requests, and hosting platforms like GitHub and Azure DevOps.

Foundations

Repository (Repo)

A repository is a centralized project folder that Git actively tracks. It stores all your files along with the complete history of every change ever made to them. Repositories can exist locally on your computer or remotely on a hosting platform like GitHub.

Remote Repository

A remote repository is a shared copy of the project hosted on a platform like GitHub. It serves as the central source of truth for the team, where everyone pushes their work and pulls updates from.

Local Repository

A local repository is your personal copy of the project stored on your machine. This is where you do your day-to-day work, making changes and committing snapshots before sharing anything with the team.

Commit

A commit is a saved snapshot of your project at a specific point in time. Each commit includes a short message describing what changed, making it easy to understand the history of a project. Commits are the foundation of version control in Git and save to your local repository only.

Staging Area

Before committing, you select which changed files to include. This is called staging. It allows you to group related changes into focused, meaningful commits rather than saving everything at once.

.gitignore

A .gitignore file specifies which files and folders Git should not track. This typically includes sensitive files like credentials, large data files, operating system files, and auto-generated content that does not belong in the repository.

Working with Remote Repositories

Push

Pushing uploads your local commits to the remote repository, making your work visible to the rest of the team. Changes remain local until they are pushed.

Pull

Pulling downloads the latest changes from the remote repository to your local machine. This keeps your local copy in sync with work that other contributors have pushed.

Sync

Usually, we don't push and pull individually. Syncing performs a pull and push together, bringing your local and remote repositories into alignment. Most Git desktop applications have this as one action.

Conflict

A conflict occurs when two branches contain competing changes to the same part of a file and Git cannot automatically determine which version to keep. Conflicts must be resolved manually before a merge can be completed.

Clone

Cloning creates a complete local copy of a remote repository on your machine. This is typically the first step when joining an existing project.

Fork

A fork is a personal copy of someone else's repository, hosted under your own account. Forking is common in open source workflows where contributors do not have direct write access to the original project.

Branching

Branch

A branch is an independent copy of your project where changes can be made without affecting the main version. The default branch is typically called "main". Branches allow multiple contributors to work simultaneously without interfering with each other's progress.

Merge

Merging combines the work from one branch into another. Once work on a feature branch is complete, it gets merged back into the main branch, incorporating those changes into the official project.

Pull Request (PR)

A pull request is a request to merge one branch into another, typically accompanied by a team review before the changes are accepted. It is not a native Git command, but a collaboration feature offered by platforms like GitHub. Pull requests are the standard workflow for reviewing and approving contributions.

Services
Process

Git

The underlying version control system. Open-source and runs locally on your machine. Git tracks changes, manages branches, and maintains a complete history of your project. Git is the engine, GitHub and Azure DevOps are built on top of it.

Service

GitHub

A cloud platform owned by Microsoft that hosts Git repositories. GitHub adds collaboration features like pull requests, issues, code review, and CI/CD through GitHub Actions. It is the most widely used Git hosting service in the world.

Service

Azure DevOps

Microsoft's enterprise DevOps platform. Includes Azure Repos for Git hosting, Azure Pipelines for CI/CD, and Azure Boards for project tracking. It includes many services outside Git, including project management and testing. It integrates natively with Microsoft Fabric.

Git Workflow Example

End-to-end workflow using git

Git Workflow

The flow of git can vary from team to team based on your strategy. Below is an example end to end flow, with multiple teams adding features simultaneously.

1Checkout Branch

Switch to the branch you want to work on. This tells Git which line of development you are contributing to.

2Clone to Local

Create a complete local copy of the remote repository on your machine. This is your private workspace, all changes start here.

3Sync to Remote

Commit your changes locally, then sync to push those commits to the shared remote branch, and pull any new changes others have made.

4Pull from Main

Periodically pull the latest changes from main into your feature branch. This keeps your branch current and reduces merge conflicts later.

5Merge to Main (Pull Request)

When your work is complete, open a pull request to merge your branch into main. This triggers a review before changes are accepted into the official project.

MAIN BRANCH A BRANCH B Pull Request pull Pull Request push sync 1. Hello 2. world 3. bye 1. Hello 2. world 3. bye 1. Hello 2. world 3. toodles 1. Hey 2. planet 3. toodles 1. Hello 2. world 3. bye 1. Hello 2. planet 3. bye 1. Hey 2. planet 3. bye 1. Hey 2. planet 3. toodles 1. Hello 2. world 3. bye 1. Hello 2. world 3. toodles Dave (Local) Git DB commit 1. Hello 2. planet 3. bye My (Local) Git DB commit 1. Hey 2. planet 3. bye

Git and Power BI

Version control for Microsoft Fabric and Power BI

Overview

This section shows how Git integrates with Power BI through Developer Mode, enabling version control, collaboration, and code review for your reports and semantic models.

Developer Mode

Power BI Developer Mode saves your report as a PBIP project folder instead of a single .pbix file. This unpacks your model and report into human-readable text files (JSON definitions, TMDL measures, and layout metadata) that Git can track line by line.

Power BI Desktop Developer Mode
saves as
PBIP
Dataset Tables, measures ..
Report Pages, visuals ..
tracked by
Git Repository Version Control
Why it matters: A .pbix file is a compressed binary. Git can't see what changed inside it. Developer Mode produces text files that enable meaningful diffs, pull requests, and collaborative code review for your Power BI projects.
Power BI Git Workflow

See how Power BI Desktop, Git, and Azure DevOps work together, from saving as a PBIP project to committing and syncing with your team through a shared remote repository.

Need help setting up Git integration for your Power BI team?

We help organizations implement version control, CI/CD pipelines, and collaborative workflows for Power BI and Microsoft Fabric.

Schedule a Call Our Offerings

Discussion

Loading comments...
1 / 7
**On screen:** Section header "Git. What version control is and why it matters." - Set framing: Git is the version control system the whole software industry uses - Two opening steps: an overview text card, then an animated diagram
**On screen:** "Overview" label. Paragraph: "Git is the version control system used across the software industry. In this section, you'll learn what Git does, why it matters, and how it helps teams track changes, collaborate, and recover from mistakes." - Set framing: this section is the **why** before the **what** - For most data folks, Git was something developers used; now it's part of Fabric and Power BI Developer Mode too *Transition:* "Quick definition."
**On screen:** "What is Git" label. Paragraph: "Git is a distributed version control system, meaning we always work on a local copy..." Animated iframe (git-flow-01). - **Distributed**: everyone has a complete copy. No single central server holds the only truth. - Tracks every change, lets teams collaborate, lets you revert mistakes - The animation shows the basic loop: edit locally, commit, sync with the team - Don't dwell here; the next sections unpack the mechanics *Transition:* "Let's get into the core building blocks."
**On screen:** Section header "Git Basics. Core commands for git." - Three concepts coming: **commits, repositories, merges** - These three words come up in every Git conversation; we want them solid before workflow gets layered on
**On screen:** "Overview" label. Paragraph: "This section covers the core building blocks of Git. We will look at the basic concepts of commits, repositories, and merges." - Three building blocks; we'll dig into commits first via an animation *Transition:* "Start with commits."
**On screen:** "Commits" label. Paragraph: "A commit is a snapshot of your project at a point in time. Think of it like a save." Animated iframe (git-commit). - A commit is a **snapshot** of the project at a moment in time - Each commit records **what changed, who changed it, and why** (the message) - Series of commits = the project's timeline - Mental model that works: think of it as a **save point**, like a video game. Goes back further than just undo/redo. - Let the animation finish
**On screen:** "Key Concepts" label. Three feature cards reveal together: **Commit** (teal, "A saved snapshot / Changes + message / A save point"), **Repository** (orange, "Your project folder / Files + full history / A shared drive with memory"), **Merge** (blue, "Combining work / Changes from two branches / Bringing work together"). - Three cards, three concepts. Walk them in order. - **Commit** = a save point. Each one captures a snapshot plus a message. - **Repository** = the project folder Git tracks. "A shared drive with memory" is the line that lands; it's a drive that remembers every version of every file. - **Merge** = combining work from two branches. We haven't covered branches yet (next section), so just plant the term: when two streams of work need to come together, merging is how. *Transition:* "Speaking of branches, that's exactly where we go next."
**On screen:** Section header "Branching. Parallel workstreams and safe experimentation." - Branching is **the** workflow concept that makes Git useful for teams - Five logical slides: Overview, What is a Branch, Branching Workflow, Branch Strategy (3 card grid), Common Strategies (GitHub Flow vs Git Flow)
**On screen:** "Overview" label. Paragraph about working on features in parallel without breaking main. - Frame the value: **work on features in parallel**, different teams on different tasks, **main stays stable** until changes are merged in *Transition:* "Branch first."
**On screen:** "What is a Branch" label. Paragraph: "A branch is an independent copy of your codebase." Animated iframe (git-branching). - A branch is an **independent copy** of the codebase - Add features or fix bugs **in isolation**, without affecting main until ready - Let the animation play; it shows the branch splitting off from main and developing in parallel
**On screen:** "Branching Workflow" label. Animation (git-branching-workflow) + teal callout: "**Sync = Pull + Push.** Most Git tools (VS Code, GitHub Desktop, Azure DevOps) offer a single 'Sync' button that first pulls the latest remote changes, then pushes your local commits." - After branching, you typically clone to your local machine - Multiple developers work on different features simultaneously, then merge back when ready - **Read the callout exactly**: Sync = Pull + Push. Most tools do this with one button. - This is the line everyone forgets; coming back to it later saves time
**On screen:** "Branch Strategy" label. Three tip-grid cards reveal together: **Main Branch** (purple, single source of truth, always stable), **Branches** (teal, short-lived hotfix/feature branches), **Best Practices** (gold, "don't commit directly to main, always branch and PR"). - A branch strategy = how your team **organizes** branches - **Main**: single source of truth. **Always stable, always deployable.** All work eventually lands here. - **Branches**: short-lived. Hotfix for bug fixes, feature for new work. Create, change, merge, **delete**. Don't let branches linger. - **Best Practices**: don't commit straight to main. Branch, review, write detailed commit messages, merge through a pull request. That's the workflow.
**On screen:** "Common Strategies" label. Two feature cards side by side: **GitHub Flow** (orange, simple) with a 2-column git graph showing Main + Feature, and **Git Flow** (blue, advanced) with a 5-column graph showing Main + Hotfix + Release + Develop + Feature. Teal callout: "**Our recommendation:** Start with GitHub Flow. It is simple, well-documented, and works for most Power BI and Fabric teams." - **GitHub Flow** (left): simpler. Main is permanent + temporary feature branches. Best for **most teams, continuous delivery.** The 2-column graph shows it clearly: branch off main, merge back, done. - **Git Flow** (right): more advanced. Main + Develop are permanent. Hotfix, Release, Feature are temporary. Best for **large teams, scheduled releases.** The 5-column graph shows the extra ceremony. - **AE recommendation**: start with GitHub Flow. Only go to Git Flow if you have a formal release process that demands it. Most teams don't. *Transition:* "Now let's lay out all the terms that come up around Git."
**On screen:** Section header "Git Overview. Key terms and concepts for working with Git." - Glossary-style section: five card grids covering **Foundations, Working with Remote Repos, Branching terms, Services, and Common Strategies recap** - Each grid presents its cards together; walk them in order
**On screen:** "Overview" label. Paragraph about walking through key Git terminology. - This is the **vocabulary** section. We've been using these words; now we define them carefully. - Six grids coming; the goal is everyone leaves with the same dictionary *Transition:* "Foundations first."
**On screen:** "Foundations" label. Six teal concept cards: **Repository (Repo)**, **Remote Repository**, **Local Repository**, **Commit**, **Staging Area**, **.gitignore**. - Walk the cards left-to-right, top-to-bottom: - **Repository**: project folder Git tracks. Can be local or remote. - **Remote Repository**: the shared copy on GitHub/Azure DevOps. **Central source of truth** for the team. - **Local Repository**: your personal copy on your machine. Where day-to-day work happens. - **Commit**: snapshot of the project at a point in time, plus a message. **Saves to your local repository only** (until you push). - **Staging Area**: the in-between. You **select which changed files** to include in the next commit. Lets you group related changes. - **.gitignore**: file that tells Git **what NOT to track**. Credentials, large data files, OS junk, autogenerated content. Important for Power BI projects because of cache files. *Transition:* "Now the verbs: what you do with a remote."
**On screen:** "Working with Remote Repositories" label. Six blue concept cards: **Push**, **Pull**, **Sync**, **Conflict**, **Clone**, **Fork**. - **Push**: upload your **local commits** to the remote. Your work only becomes visible to others after a push. - **Pull**: download the **latest changes** from the remote to your local. Keeps you in sync with the team's work. - **Sync**: **push + pull together**. Most desktop apps offer this as one button. (Same line from the Branching section; it's worth repeating.) - **Conflict**: when two branches change **the same line of the same file** and Git can't auto-merge. You resolve manually. This is the scary one; it's not actually scary once you've done it twice. - **Clone**: make a complete local copy of a remote repo. **First step when joining a project.** Different from fork. - **Fork**: a personal copy of someone else's repo, under your account. Common in open source. Different from clone because you own the fork; it's not connected to the team's main remote.
**On screen:** "Branching" label. Three orange concept cards: **Branch**, **Merge**, **Pull Request (PR)**. - **Branch**: independent copy. Default is **main**. Multiple contributors work simultaneously without stepping on each other. - **Merge**: combine work from one branch into another. Feature branch -> main when work is complete. - **Pull Request**: a request to merge one branch into another, **typically with team review**. **Not a native Git command** -- it's a feature of GitHub/Azure DevOps. Worth calling out because people use "PR" interchangeably with "merge" and they aren't the same thing.
**On screen:** "Services" label. Three concept cards: **Git** (teal, "Process"), **GitHub** (purple, "Service"), **Azure DevOps** (purple, "Service"). - **Git** (the process): the **underlying version control system**. Open-source. Runs locally. GitHub and Azure DevOps are built on top of it. - **GitHub** (the service): cloud platform **owned by Microsoft** (worth saying out loud; some people still don't know). Adds collaboration features: pull requests, issues, code review, GitHub Actions for CI/CD. Most widely used Git host. - **Azure DevOps** (the service): Microsoft's enterprise platform. Includes **Azure Repos** (Git hosting), **Azure Pipelines** (CI/CD), **Azure Boards** (project tracking). **Integrates natively with Microsoft Fabric.** This is the one Fabric shops typically use. *Transition:* "Last grid; common strategies recap."
**On screen:** Section header "Git Workflow Example. End-to-end workflow using git." - Worked example tying the vocabulary together - Two logical slides: the 5-step workflow card grid, then the full git-graph diagram
**On screen:** "Git Workflow" label. Five numbered tip-grid cards: **1. Checkout Branch**, **2. Clone to Local**, **3. Sync to Remote**, **4. Pull from Main**, **5. Merge to Main (Pull Request)**. - Walk the five steps in order; they map to the day-to-day flow: - **1. Checkout Branch**: switch to the branch you want to work on. Tells Git which line of development you're contributing to. - **2. Clone to Local**: complete local copy of the remote. Your **private workspace**. All changes start here. - **3. Sync to Remote**: commit locally, then sync (push + pull) to share with the team and grab their updates. - **4. Pull from Main**: periodically pull main into your feature branch. **Keeps your branch current and reduces merge conflicts later.** This is the step that gets forgotten and causes nightmares. - **5. Merge to Main (Pull Request)**: when work is complete, open a PR. Triggers review. Then merge. - The whole cycle: checkout -> clone -> work -> sync -> stay current -> PR -> merge.
**On screen:** Detailed git graph SVG. Three vertical columns: **MAIN** (blue, center), **BRANCH A** (green, right), **BRANCH B** (teal, left). Two local-workspace boxes on the right: **Dave (Local)** purple and **My (Local)** orange. Code panels show file contents changing across commits (Hello/world/bye -> Hello/planet/bye -> Hey/planet/toodles). Arrows labeled push, sync, pull, Pull Request connect everything. - This is the synthesis diagram. **Don't read every node; tell the story.** - Two developers (Dave and "My") working in parallel on two branches off Main. - Watch the file content evolve: Main starts with `1. Hello / 2. world / 3. bye`. - **Branch A** changes `world` to `planet` (purple highlight), commits, eventually PRs back into Main. - Meanwhile **Dave** is on his local copy editing `bye` to `toodles` (teal highlight), syncing through Branch B. - The pull arrow shows Main flowing back into Branch A so it stays current. - Final Main commit shows all three changes merged together: `1. Hey / 2. planet / 3. toodles`. - Point at the workflow, not the geometry. The takeaway: **Git lets parallel work converge cleanly without anyone losing their changes.** *Transition:* "Now: how this applies to Power BI."
**On screen:** Section header "Git and Power BI. Version control for Microsoft Fabric and Power BI." - Bring it home: how all this applies to Power BI - Three steps: overview, Developer Mode + PBIP, end-to-end animation
**On screen:** "Overview" label. Paragraph about Developer Mode enabling version control for reports and semantic models. - The bridge: Git was developer territory until **Power BI Developer Mode** made it work for BI *Transition:* "Developer Mode itself first."
**On screen:** "Developer Mode" label. Paragraph about PBIP project folders. Three-node diagram: **Power BI Desktop** (Developer Mode) -> "saves as" -> **PBIP** (folder showing Dataset and Report subfolders with file icons) -> "tracked by" -> **Git Repository**. Teal callout: "**Why it matters:** A .pbix file is a compressed binary. Git can't see what changed inside it. Developer Mode produces text files that enable meaningful diffs, pull requests, and collaborative code review for your Power BI projects." - **Developer Mode** saves the report as a **PBIP project folder** instead of a single .pbix file - The folder structure: **Dataset** (tables, measures, TMDL) + **Report** (pages, visuals, layout JSON) - All **human-readable text files**. Git can track them line by line. - **Why this matters** (read the callout): .pbix is binary; Git can only see "the file changed." PBIP is text; Git can show **exactly which measure was edited, exactly which visual was moved.** That's the unlock that makes PRs, code review, and meaningful diffs possible for Power BI work.
**On screen:** "Power BI Git Workflow" label. Paragraph + animated iframe (git-01) showing Power BI Desktop + Git + Azure DevOps working together. - End-to-end animation: Power BI Desktop -> PBIP save -> Git commit -> Azure DevOps remote -> team collaboration - Let it play. The narrative is built into the animation timing. - Closing line: **everything we covered in Git applies here. PBIP just made Power BI a first-class citizen.** *Transition:* "Questions?"