What Power BI Developer Should Know About Git

Spread the love

git - what Power BI developer should know

What is Git, and why should you care? “Git is a free and open-source distributed version control system designed to handle everything from small to very large projects with speed and efficiency”. For Power BI people it means that you don’t need to use MyReport v1.pbix, MyReport v2.pbix, …, MyReport vn.pbix for your version control. Also, you have version history so that you can revert back to the wanted version. Moreover, it gives you the possibility for multiple people to work on the same file. But before I can talk about how to do that (this will be written in another post), you must learn about Git first. 

Git Concepts

There are a few concepts that you need to understand before working with Git.


You can think about a repository (or repo) as a folder. You create different repos for different projects, and there, you save all your files related to it — also, the ones you want to have for version control. So, Git will track all the changes you will make to your files, and you will have your changes history.

While working with Git, you should have online/remote and local versions of your repo. For example, suppose you’re working on a Sales Analysis report. In that case, you should have a local repo called “SalesAnalysisReport” on your machine (e.g., your computer) and a “SalesAnalysisReport” remote repo (e.g., in GitHub or Azure DevOps repos). You can say you have a remote repo, and its clone on your machine, aka local repo. 

The local repo will be a place where you will work with your files and make changes, and from time to time, you’ll sync it with the online/remote repo, similarly as you’re doing now with Power BI Desktop and Power BI Service. 

Pull, Stage and Commit, Push


Commit is a snapshot of your repo at the time it is done. When you work with your files, at some point, you will want to record the current files stage to collect a history. So, you commit (or you could say “save”) your changes to your project’s repo.

When doing a commit, you must add a descriptive message about what you did. It tremendously helps when reviewing history. 


Before doing a commit, you need to select (aka stage) what you want to commit. It means that you can commit not all changes that you made.


Pulling means you’re coping/cloning/syncing your remote repo to your local. 

So, before committing your changes, you should always do a Pull to have the latest remote repo version.


Pushing means that you’re publishing/uploading, aka pushing, all your local changes (commits) to your remote repo. Then, everyone using this repo will see and use your changes for their work.


You can say that a branch in Git is a collection of commits where you can point to a specific commit. This is how you can visualise your changes and their history. Branching in Git lets you work with multiple branches. You will always have one main branch and feature branches (at least one). You can think about it as a production (main) branch and development (feature) branch(es). This is how you can work on multiple tasks simultaneously and have a clean history.


When you work with multiple branches, at some point, you will finish your changes and want to save your work in the main branch. This action is called merging.

There are multiple ways to save your changes from the feature branch to the main, e.g.,  merge, rebase or squash. But as for a beginner, it’s advised to use merge, so I won’t talk about other options in this post.


So, how does all of this work? As I wrote at the beginning of this post, there will be another post where I will show you exactly how to work with Git and Power BI. Until then, I would like to share an example of how you can work with Git (if you don’t have anything set up yet). Note: It’s not the only way to do it!

The steps could look like this:

  1. Create a Remote Repo (could be in GitHub or Azure DevOps) for your project
  2. Upload all the files you want to use for version control
  3. Create a Local Repo with Git (could be with Visual Studio Code) by cloning the remote one
  4. Create a Feature Branch in the Local Repo
  5. Make your changes
  6. Stage changes you’ll want to commit
  7. Commit
  8. Push your commits to the Remote Repo
  9. Merge your feature branch with the main branch

Ending Note

I hope now you understand the most basic Git concepts and why it could be helpful to use it. In the next post, I’ll describe how to integrate and use it for Power BI.

Spread the love

2 thoughts on “What Power BI Developer Should Know About Git”

Leave a Comment

Your email address will not be published. Required fields are marked *