Streamline collaboration in Microsoft Fabric with a simple Git branching strategy

[ruicunha]

Introduction

Microsoft Fabric is a unified data platform that brings together various analytics experiences—such as data engineering, data science, real-time analytics, and business intelligence—into a single, integrated environment. One of its most compelling strengths lies in its ability to foster collaborative work across teams, enabling seamless cooperation between data professionals, developers, and business users.

Fabric's collaborative potential is deeply rooted in its workspace-centric architecture, where artifacts like notebooks, pipelines, datasets, and reports are shared and versioned within a common environment.

A key enabler of this collaboration is the integration of Git into Microsoft Fabric. By connecting Fabric workspaces to Git repositories, teams can:

• Version control their artifacts, ensuring traceability and rollback capabilities.
• Collaborate asynchronously, with multiple contributors working on different branches.
• Review and approve changes through pull requests, enhancing governance and quality.
• Automate deployments and CI/CD workflows, aligning data development with software engineering best practices.

In the following sections of this article, we will explore best practices for using Git within Microsoft Fabric, focusing on a simple Git branching strategy aiming to maximize collaboration, maintain code quality, and streamline deployment processes.

Key Considerations Before Starting Your CI/CD Journey in Microsoft Fabric

Before embarking on your CI/CD journey in Microsoft Fabric, one crucial consideration is whether your Fabric workspaces should be segregated by team. Different teams within an organization often have distinct areas of expertise, development practices, and delivery cadences. Establishing clear boundaries while allowing each team the autonomy to work in their preferred way can significantly enhance productivity and reduce friction.

Our recommendation is to assign separate workspaces to different teams, as each team can manage its own source control repositories and deploy content to higher environments at its own pace. This setup not only supports independence but also aligns better with varied workflows across the organization.

The workspace setup directly influences your Git branching strategy. Whether teams share a single workspace or operate in isolated ones has a significant impact on how version control is structured and managed. In a non-seggregated workspace setup, multiple teams with different development and release cycles must coordinate closely. This often requires a more complex Git strategy to handle parallel workstreams, resolve conflicts, and maintain stability.

In a segregated workspace setup, each team has exclusive control, allowing for simpler and more focused branching strategies tailored to their specific cadence and workflow.

This distinction underscores the importance of thoughtful workspace planning, especially when integrating Git in collaborative environments.

In this article, we’ll explore a scenario where each team is assigned its own workspace. With this setup in place, we’ll shift focus to another critical aspects in the CI/CD journey in Microsoft Fabric: the development process and the Git branching strategy adopted.

The Development Process

We’ll examine a common setup where development teams primarily use client tools such as Power BI Desktop, Visual Studio Code, and the Fabric UI as part of their workflow. This combination supports a flexible and efficient development process while leveraging the full capabilities of Microsoft Fabric.

This leads us to a combination of two scenarios:

Scenario 1: Development is carried out in the developer’s preferred IDE, using a local Git repository. Changes are then pushed to the remote Git repository associated with the feature workspace.

Scenario 2: Development is carried out directly in the Microsoft Fabric UI.

With workspace segregation by team and the development process now defined, we can move on to another critical aspect: the Git branching strategy. 

Why Defining a Git Branching Strategy Is Essential

A Git branching strategy is essential for enabling efficient collaboration and ensuring reliable version control within your Microsoft Fabric projects. It defines how code is organized, developed, and integrated, allowing your development teams to work in parallel with clarity and control. A well-defined strategy helps prevent conflicts, supports code reviews and testing, and accommodates different development cycles—ultimately promoting both agility and stability in solution delivery.

As you know, the Fabric workspace is a shared environment that accesses live items. Changes that you make directly in the workspace will affect all other workspace users. Therefore, as Git best practice in Fabric, developers should work in isolation outside of the environment (shared) workspaces, creating their own workspaces, also known as feature workspaces. Examples of shared workspaces are the environment workspaces (DEV, UAT, and PRD, for example).

This next diagram illustrates a simple branching strategy that can be used in Microsoft Fabric.

Once the environment branches are created, whenever a developer begins working on a new feature, they can use the branch out feature to create a new feature branch and associate it with a new feature workspace.

After completing the feature development and unit testing within the feature workspace, the developer uses the Git Pull Request functionality to merge their code into the Dev branch.

Once the merge is complete, the Git code should be published to the Dev workspace (using the Update feature in the Fabric UI or using Fabric Git APIs) . After the update, the code becomes available in the shared Dev workspace, where integrated testing can be performed, for example.

Once the code is reviewed in the Dev workspace, it can be promoted to the UAT or PRD workspaces using the Git Cherry Pick functionality. Why do we suggest using the Git Cherry Pick instead of the Git Pull Request in this case?

Let’s consider a scenario where two independent features have been promoted to the UAT environment and are being tested by the Quality Assurance team. One of the features is rejected because it does not meet business requirements and needs to be adjusted. However, the other feature is approved and ready for promotion to the production environment.

If we were to perform a Pull Request from UAT to PRD, we would be promoting both features, which is not desirable. By using Git Cherry Pick, we can selectively promote only the approved feature to the PRD environment.

Here’s one practical example (we are using Azure DevOps as our Git provider):

After merging several features into the DEV workspace, we want to promote only one of those features to the UAT workspace.

To do this, we’ll go through the commits in the DEV branch and select the commit associated with the specific feature we want to promote.

Once the commit is selected, you can click the action button in the top-right corner and choose the "Cherry Pick" option

Next, you’ll need to specify the target branch—in this case, we want to promote the change to the UAT workspace.

You’ll also be prompted to name the new branch that will be created with this feature. In this example, we’re keeping the default name.

 

When you click the "Cherry Pick" button, a new Pull Request will be created, containing the files associated with your feature.

The source of the Pull Request will be the cherry-pick branch, and the target will be the UAT branch.

After completing the Pull Request, you can delete the cherry-pick branch, as it will no longer be needed in the repository.

Once this process is complete, you can propagate the feature from the UAT branch to the UAT workspace using the "Updates" option in the Source Control blade (you can automate this update by using this release process).

Therefore, the recommendation is to use Pull Request when promoting code between feature workspaces and Dev, and to use Git Cherry Pick when promoting code between environment workspaces.

Conclusion

Maximizing collaboration in Microsoft Fabric hinges on thoughtful workspace design and a streamlined Git branching strategy. By segregating workspaces by team and leveraging Git integration, organizations empower their data professionals to work independently yet cohesively, minimizing conflicts and enhancing code quality. The recommended approach—using feature workspaces for development, pull requests for merging into shared environments, and cherry-pick for selective promotion—ensures agility, traceability, and control throughout the development lifecycle. Adopting these best practices not only simplifies collaboration but also aligns data analytics workflows with proven software engineering principles, enabling teams to deliver robust, scalable solutions in Microsoft Fabric.

This article was written with the valuable contribution of my colleague Antonio Dente, Sr. Technical Advisor - Azure DevOps.