top of page

Commit three times, and revert the second commit. Power BI Version Control in Azure DevOps.

  • Jihwan Kim
  • Jul 23, 2023
  • 3 min read

In this writing, I like to share what I have tested when version controlling in Power BI with Azure DevOps.


Recently, I could experience how much efficient and effective the version control is with Git Integration in Power BI Workspace. And I wanted to step further and learn more about it. The first thing that came up to me was how can I go back to the previous version, and what will happen if I did three commits but reverted the second commit.


Firstly, I like to share how I do one commit and how I revert the last commit.


In PBIP file, create two new visualizations like below.

ree


Commit the change is VS Code. And Git Graph in VS Code shows like below.

ree


After synchronizing, Azure DevOps shows the change like below, and Power BI Workspace also shows the change.

ree

ree

ree

However, if your team does not like the two visuals that are added to the report, you can decide to revert the last change in Azure DevOps.

ree

ree

ree

ree

In the below, you can choose an option other than "Merge (no fast forward)", and the diagram appears to briefly explain how the branch will change.

ree

ree

After synchronizing Power BI workspace, the report will show no visuals that are created in the last commit.


But, how about the PBIP file stored on the local computer?

On the local computer, VS Code still shows the last commit which is "Add two visualizations".

ree

However, after synchronizing with Azure DevOps, it shows what happened in Azure DevOps (reverts the last commit).

ree

And magically, when you open PBIP file, it shows no visuals.

ree

This makes all three areas, Power BI Workspace | Azure DevOps | Local PBIP file, show the same.




Secondly, I will do three commits and revert the second commit, and let's find out what happens.


My assumption is, the first and the third commit still remain but only the second commit will be undone.


First commit: Add a DAX measure.

Second commit: Fix the DAX measure that is added in the first commit.

Third commit: create a visualization with the DAX measure.


First commit: add a new DAX measure = [Top one customer measure:]

ree

ree



Second commit: fix the DAX measure

ree

ree


Third commit: add a visualization using the new measure.

ree

ree



All are synchronized to show changes in Azure DevOps and Power BI Workspace.

ree

ree

ree



Revert the second commit.

ree

ree

All steps about how to revert are already described above so I skip those.


Once the revert is finished, the below diagram is shown.

ree

In Power BI Workspace, there is one notice that indicates only the dataset is changed that needs to be updated. This means that the new visualization that is added in the third commit will remain.

ree


As a result, the DAX measure without the KEEPFILTERS function in the visualization is shown below.

ree


And, after synchronizing in VS Code, the PBIP file in the local computer also shows the visualization without the KEEPFILTERS function.

ree

ree



To summarize, if there are no conflicts, the commit that you revert only is applied, and the rest of the commits still remain without any changes. If you have the first commit | second commit | third commit, and if you revert the second commit, the first and the third still remain in the PBI report.


And I need to consider and come up with a decision about how small the commit I should make.

Every line change in the DAX formula should be one commit?

Or, the changes in one DAX formula should be one commit?

Or, one visualization should be one commit?

I totally agree with the saying, "If you commit big, you have to undo big". And my homework is to define how much workload is the optimal size of each commit.


I hope this helps to have more fun in playing with Azure DevOps and VS Code for Power BI Version Controlling.

Comments


bottom of page