dia•chroma

Power BI
Version
Control
THE KEY CONCEPTS
 dia•chroma

In this guide, I will introduce you

to some key concepts to grasp
the mechanism of version
control in Power BI and its
essential terms.
 dia•chroma

Version Control
This system allows you to track the different
versions of a project (managing versions)
and facilitates collaborative work.

Multiple developers can work on different

parts of a project at the same time without
overlapping or conflicting (simultaneous
development).
 dia•chroma

Git
This is a version management system. It
tracks changes made to files, creates
branches, commits, and so on.

Git is a tool that can be used locally on your

computer or on remote servers.
 dia•chroma

Azure DevOps
A comprehensive development and
deployment platform.

It provides services for tracking bugs,

planning tasks, CI/CD (Continuous
Integration and Continuous Delivery), and of
course, hosting Git repositories (through
Azure Repos).
 dia•chroma

Azure Repos
This is where your Git repositories are hosted
online. Think of it as a central warehouse for
your code (or your Power BI dashboards in
this context).

Git is the tool you use to interact with these

repositories, be it locally on your machine or
when syncing with Azure Repos.
 dia•chroma

Repos (or repositories)

Picture a folder where you store all your Power
BI files. A repo (short for "repository") is that
folder, but online.

You have a Power BI project to analyze your

company's sales. You create a repository for
this project, which lets you track changes,
collaborate with others, and have a history of
all versions.
 dia•chroma

Files
These are the individual files contained within
your repository. This could be your Power BI
reports.

In your project, you have a file named "Sales

Report.pbip" that houses the dataset and your
visualization report.
 dia•chroma

Clone
It's when you take an online-hosted Git
repository (like on Azure DevOps or GitHub)
and make a full copy of it on your computer to
work on it locally.

You wish to work on the Power BI dashboard

from home. You "clone" the repository to your
computer, make your edits, and then update
the online version later.
 dia•chroma

Branch
Imagine wanting to test a new feature without
impacting the main version of your project.
You create a "branch" to work on it, separate
from the main branch.

You're considering introducing a new type of

chart but are unsure about keeping it. You
create a branch, add the chart there, and if
everything goes well, you can merge this
branch with the main one.
 dia•chroma

Commit
Every time you make a set of changes to your
files and wish to save these alterations, you
make a "commit". It's like taking a snapshot of
your files at a specific moment.

You add a new visualization to "Sales

Report.pbip". After ensuring everything works,
you "commit" the changes to capture this state
of the file.
 dia•chroma

Push
After making one or more commits on your
computer, you "push" these commits to the
online repository so everyone can see them.

After committing various changes throughout

the week, you "push" these commits to Azure
DevOps so your team can view and use the
latest versions.
 dia•chroma

Pull
It's the opposite of "push". If others have made
changes online, you "pull" these changes to
your local version to stay updated.

Your colleague added a new filter to the online

dashboard. You "pull" these changes to have
this new filter on your computer.
 dia•chroma

Pull Request
When you're done working on a branch and
want to add your changes to the main version,
you ask others to review your changes via a
"pull request". It's a request to merge your
changes.

You've finalized the new chart design in a

branch. You create a pull request so your team
can check it before integrating it into the main
version.
 dia•chroma

Merge
After reviewing a pull request and everything
looks good, you can "merge" this branch with
the main one. This adds all the changes from
that branch to the main branch.

The new visualization you added in a separate

branch looks great. After a pull request, you
"merge" this branch with the main one, so
everyone can utilize this visualization.
 dia•chroma

Conflict
If two people modify the same thing at the
same time, Git isn't sure which version to keep.
This creates a "conflict" that you have to
manually resolve.

Both you and a colleague have edited the title

of a chart. When you try to merge your
changes, Git indicates there's a conflict and
asks you to decide which title to keep.
 dia•chroma

Now, let's explore

how to put all this
into action.
 dia•chroma

Initialization
Developers use Azure DevOps to create a Repo
titled "Reporting Sales".

Inside this repo, they add the initial file named

Sales report.pbip.
 dia•chroma

Local work
Lucas, a developer, clones (meaning copies)
the repo to his computer to have a local
version.

He wants to add a new visualization, so he

creates a branch named "add-visualization".
 dia•chroma

Modification &
Commit
In this branch, Lucas edits the Sales
report.pbip and adds his new visualization.

Once he's happy with his work, he commits his

changes with a message like "Added sales
visualization by region".
 dia•chroma

Parallel work
Meanwhile, Sophie, another developer, wants
to fix an error in a chart. She too creates a
branch, naming it "chart-fix", and makes her
changes.

She commits her changes with the message

"Corrected the Y-axis of the chart".
 dia•chroma

Push & Pull Request

Lucas is ready to share his changes with the
team. He pushes his branch to the repo on
Azure DevOps.

He then creates a Pull Request (PR) so his

colleagues can review his changes.

Sophie does the same with her branch.

 dia•chroma

Review & Merge

The team reviews Lucas's PR. After some
discussions and possibly some adjustments,
they approve his changes.

They merge the "add-visualization" branch into

the main branch.

They then review Sophie's PR and do the same.

 dia•chroma

Conflicts
Sometimes, two people might modify the same
part of a file. Let's say Sophie and Lucas both
changed the same visualization. When they try
to merge their branches, Git will flag a conflict.

In this case, they'll need to resolve the conflict

(i.e., decide which change to keep) before they
can merge.
 dia•chroma

Tags (optional step)

Once all the changes are merged and the

dashboard is updated, the team decides this
version is ready for a presentation. They add a
tag to this specific commit, calling it
"Annual_Presentation_Version".
 dia•chroma

Continuation
The team continues to work in this manner,
creating branches for new features or fixes,
committing changes, pushing branches,
making PRs, merging, and so on.
 dia•chroma

This is an overview of simplified

key concepts to help you grasp
Git's integration into Power BI.
For a comprehensive mastery of
these tools, it's recommended to
undertake beginner Git training
courses.

(Links in comments below)