top of page
Jihwan Kim

Understanding Conflicts and Smooth Pull Requests in Azure DevOps for Power BI

In this writing, I want to share my experience of altering the same report using different branches and PBIP files, and committing those changes to Azure DevOps. I'll discuss the issues that arose, detailing why two pull requests faced conflicts.


Sometimes, two people are assigned tasks to work on the same Power BI report. In such cases, one person might wait for the other to finish their task. I decided to investigate a scenario where each person uses a different branch stemming from the same main branch and commits their changes independently, without waiting for the other to complete their task and clear the ticket.




In this experiment, I'll create two branches from the main branch in each scenario and then assess whether conflicts arise or not.


In each scenario, two branches are presented such as:


**branch01:** Adding an existing measure to the line chart visualization

versus

**branch02:** Changing title text color and style, and line color in the line chart

-> Conflict or not?


**branch03:** Addition of a measure to the line chart

versus

**branch04:** A fix made to a DAX measure in the line chart.

-> Conflict or not?


**branch05:** Addition of a measure to the line chart

versus

**branch06:** Fix the title font color

-> Conflict or not?


**branch07:** Fix a measure and add it to the line chart

versus

**branch08:** Fix a measure that is already in the line chart.

-> Conflict or not?


**branch09:** Addition of a measure to the line chart

versus

**branch10:** Fix the title font color and fix the DAX measure that is in the line chart

-> Conflict or not?


This lays the groundwork for the detailed exploration of the following experiment.




In the Dev_workspace, there exist two reports and two semantic models. Git integration is set up within the workspace, and it is linked to Azure DevOps as illustrated below. In this experiment, I only use Product_PBIP.pbip file.

The following steps outline how to create sub-branches from the main branch in Azure DevOps.

The following explains how to clone each sub-branch in VSCode and on my local machine.



In the branch named branch01, a modification has been made to the Product_PBIP file, involving the addition of a profit measure to the line chart visualization.



Branch02 has been created prior to the commit mentioned above. I cloned Branch02 to VSCode and my local machine as outlined below.



In branch02, the following changes have been made.

- Text color and text style modifications in the title.

- Line color alteration in the line chart.




I attempted to initiate a pull request for branch01 as outlined below.






The outcome of this pull request is detailed as follows in the report within the Dev_workspace.



Now, let's proceed with another pull request for branch02.


The merge was unsuccessful, and a conflict is indicated, as shown in the picture below.




Revert the changes made above, and create branch03 and branch04.




As illustrated in the figure below, branch03 outlines changes to the line chart, specifically the addition of a measure. Branch04 describes the fix made to one DAX measure.



Following the pull requests for branch03 and branch04, there were no conflicts, and both sub-branches were successfully merged into the main branch.

In the power bi report in Dev_workspace, it also shows that the two merges are successful.



Once again, revert all the changes made above, and then create branch05 and branch06 to experiment with different modifications.

Although I haven't included all the pictures for creating branch05 and branch06, let me explain in writing. In branch05, the change involves adding a measure to the line chart, while in branch06, the modification focuses on fixing the title font color in a different visualization. The outcome reveals a conflict.


Next, I create branch07 and branch08. The changes made in each branch are described in the figure below. Branch07 involves adding a measure to the line chart and fixing the measure before adding it. On the other hand, Branch08 focuses on fixing a measure that is already present in the line chart.

As a result, there are no conflicts.


It also reflects successfully in the report within the Dev_workspace.


Finally, after reverting to the state before the changes, I create branch09 and branch10. Branch09 indicates the change of adding a measure to the line chart. Branch10 involves fixing the text color in the title and correcting the DAX measure in the line chart.


As depicted below, a conflict occurred.



Conclusion


In summary, these experiments looked at how we can change and combine work in Azure DevOps, focusing on the same report in the workspace. I tried different things in five cases, and in each case, I saw unique comparisons and issues.


The experiments showed that making conflicts depends on what changes you create in the branch. Sometimes, changes in the same part of the report create conflicts, but other times, things blend smoothly. It's crucial to understand how branches work and how changes affect the report.


I also saw that good practices, like smart branching and clear communication in the team, make working together easier. By doing this, we can reduce conflicts and make our work more efficient.


In summary, going through branches 01 to 10 in five cases taught me valuable lessons about teamwork with Power BI and Azure DevOps. By using branches smartly, communicating well, and being aware of possible issues, teams can handle version control challenges smoothly, making the development process better.

328 views0 comments

Comments


bottom of page