~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
Version control fundamentals for Microsoft Fabric and Power BI developers
Version Control • Branching • Collaboration • Developer Mode
What version control is and why it matters
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.
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.
Core commands for git
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.
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.
Parallel workstreams and safe experimentation
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.
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.
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.
A branch strategy defines how your team organizes branches.
The single source of truth. Always stable, always deployable. All work merges back here.
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.
Try not to commit directly to main. Always branch, review, write detailed commit messages, and merge through a pull request.
There are many branch strategies that vary in complexity. Below are two of the more common.
Key terms and concepts for working with Git
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Cloning creates a complete local copy of a remote repository on your machine. This is typically the first step when joining an existing project.
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.
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.
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.
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.
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.
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.
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.
End-to-end workflow using git
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.
Switch to the branch you want to work on. This tells Git which line of development you are contributing to.
Create a complete local copy of the remote repository on your machine. This is your private workspace, all changes start here.
Commit your changes locally, then sync to push those commits to the shared remote branch, and pull any new changes others have made.
Periodically pull the latest changes from main into your feature branch. This keeps your branch current and reduces merge conflicts later.
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.
Version control for Microsoft Fabric and Power BI
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.
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.
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.