Working with Microsoft Fabric Git integration and multiple workspaces

Reading Time: 7 minutes

In this post I want to cover working with Microsoft Fabric Git integration and multiple workspaces. By highlighting one method that you can use in the real-world.

I must admit that I have been very keen to test this particular way of working with Microsoft Fabric Git integration and multiple workspaces.

By the end of this post, you will know one way that you can work with Microsoft Fabric Git integration and multiple workspaces. Based on real-world working practices. Including multiple branches and pull requests.

In addition, I share the results of other tests performed and one way to avoid merge conflicts.

If you need help with any jargon used in this post you can read my other post which is a Microsoft Fabric Git integration jargon guide for Fabricators.

One key point to note is that Microsoft Fabric is now generally available. You can read more about this in detail in the official post by Ryan Majidimehr.

Overview of Microsoft Fabric Git integration

Just to clarify, Microsoft Fabric Git integration allows you to synchronize supported items in a Microsoft Fabric workspace with a Git repository stored in Azure DevOps.

At this moment in time, the supported items for Microsoft Fabric Git integration are Lakehouses, notebooks, reports, paginated reports and semantic models(datasets). This opens up some interesting options.

For example, you can work with a Power BI project locally and then synchronize it with a Git repository in Azure DevOps. Which can then be used to work with one or more workspaces. Like in the below diagram.

Note that in the above diagram the arrows go both ways. To highlight that changes can be bi-directional.

To manage expectations, even though this diagram shows Power BI this post focuses solely on working with Microsoft Fabric and Azure DevOps. In other words, it shows how to work with the two services to the right of the above diagram.

However, if you are keen to perform the work pattern shown in the above diagram from left to right then I highly recommend that you read my previous post first. Which covers my initial Microsoft Fabric Git integration tests for Power BI Reports.

Due to the fact that in that post I cover how to work with Power BI projects and Azure DevOps together. So you can read that one first and then combine it with the details in this one.

One final thing to add about this is that the Git integration feature also works with a Power BI Premium license. You can read the Fabric prerequisites for further details.

Examples in this post

For this post I used my own Microsoft Fabric public preview environment which contains two workspaces. One that I worked with in my previous post and another to represent a production workspace.

In addition, an Azure DevOps organization that I created in the same environment.

To follow along with this post you can read my other post that covers how to create your own Microsoft Fabric environment. Which includes how to setup both Microsoft Fabric and Azure DevOps.

Creating a new branch in a Microsoft Fabric workspace

First, I went into the Microsoft Fabric workspace that I created in my previous post and clicked on ‘Source control’. I then selected ‘Checkout new branch’. Which allowed me to create a new branch based on the main branch directly within Microsoft Fabric.

Once done I then checked that the new branch had been created in Azure DevOps.

I then went back into the workspace where I had just created the new Dev branch and changed the description of an existing report. After clicking refresh in the browser I got alerted that a change was uncommitted.

So, I committed the change and then went back into Azure DevOps and selected ‘Branches’. To check that the new branch was ahead of the main branch.

I then created my second workspace and configured Git integration to use the original main branch.

Which then synced up all of the original objects that had existed in the main branch before I had created a new one.

To check that it was based on the original contents of the main branch I went into the settings of the report I had changed in the other branch. I then checked that it still showed the original description.

Updating the main branch

In reality, there are two main options I can use to update the main branch that the new workspace uses.

First option is to change the main branch to use the Dev branch instead in the Git integration settings.

Second option is to align with modern CI/CD practices and raise a pull request to update the main branch.

In this post I do the second option to show good working practices. I started the process directly in Microsoft Fabric by going into source control and select ‘View ADO repository’.

Which took me straight to the Azure DevOps repository that the workspace uses for Git integration. Azure DevOps recognized the fact that I new Dev branch had been updated and very kindly invited me to create a pull request.

When I clicked the button to create a pull request, I was greeted by something that I personally think is a nice touch. Because it opened up a new pull request screen that already contained details about the changes in the workspace.

It would have been nicer if it had referenced the workspace name as well. However, it is still a nice touch.

In the real-world you include more details in the pull request form. For example, by adding a link to whichever work item in Azure Boards you were working on. Which is great if you are working on a Power BI report as part of a work item during a sprint.

Plus, you can also add reviewers. With this in mind, I added a reviewer before clicking the create button. Which took me to the below pull request details screen.

From there I completed the pull request.

Important pull request advice if working with Microsoft Fabric Git integration

One key point I want to highlight is that if you want to keep the same branches in-place you must deselect the option to delete the other branch after merging. Otherwise, you will have to recreate it in Microsoft Fabric.

In addition, if you intend to work with branches this way then it is very important that you also do not click the blue button to delete the source branch in the pull request once completed.

However, if you are working on a temporary workspace to test a new feature and you are working with a short-term feature branch in that workspace deleting the branch is fine.

Anyway, once completed I closed the pull request by closing the open Azure DevOps tab.

Updating new workspace in Microsoft Fabric

Back in Microsoft Fabric, I went into the new workspace that represents a production one and got notified that there is an unsynced commit.

So, I went back into Source control and selected ‘Update all’.

Once done I could see that the report had synchronized, and the description had been updated.

Other Microsoft Fabric Git integration tests with multiple workspaces

I repeated the above process multiple times and tested doing various things. In addition, I also tested doing an undo in the Dev workspace. Which all worked fine.

Plus, I tested what would happen when I created a new report in the Production workspace first. Which is where things got a bit interesting.

Because unlike some other mechanisms, any new items that you add to other workspaces that uses a separate Git branch will stay there. Even after the synchronization has completed.

Providing that the items have different names. Otherwise, you will get a merge conflict when you go to complete your pull request. As you can see below.

Which can take a bit of effort to fix.

Final words about Microsoft Fabric Git integration with multiple workspaces

I hope me sharing how you can work with Microsoft Fabric Git integration and multiple workspaces has made for an interesting read.

Because I want to inspire others to think about how they can work with multiple workspaces and branches in their environment.

Of course, if you have any comments or queries about this post feel free to reach out to me.