Forum Discussion
Fabric Git Integration issue for multiple branch creation in UI
We have integrated Microsoft Fabric workspace with GitHub and connected the workspace to a dev branch. Our objective is to allow multiple developers to work in parallel on the same Fabric items (e.g., notebooks, pipelines, semantic models) by creating their own Git branches, without seeing each other’s changes until they explicitly commit and merge. However, we are observing unexpected behaviour when multiple developers work in the same workspace.
Current Setup
- Microsoft Fabric workspace connected to GitHub
- Workspace connected to dev branch
- Multiple developers have Contributor access to the same workspace
- Each developer:
- Creates their own Git branch (e.g., feature/dev1, feature/dev2)
- Works on the same Fabric item (e.g., notebook) inside the same workspace
- Does not switch workspace Git branch in Fabric UI before editing
Observed Behaviour (Actual)
- Developers can see each other’s in-progress changes immediately in the Fabric UI, even:
- Before committing changes
- Without switching branches in the workspace
- Changes appear workspace-scoped, not branch-scoped
- This results in:
- Overwrites of in-progress work
- Confusing Git diffs
- Merge conflicts where only the last writer’s changes appear in Fabric
- Branch isolation does not work as expected when using a single workspace
Expected Behaviour
- Each developer’s Git branch should act as an isolated working copy
- A developer should:
- Only see their own changes in their branch
- Not see other developers’ changes unless:
- Changes are committed
- Merged into the workspace-connected branch
- Workspace is explicitly synced
We would like to know if it is supported to have multiple Git branches actively editing the same Fabric workspace while maintaining isolation?
If not:
- Is this behaviour by design in Fabric?
- Is branch isolation intentionally not enforced at workspace level?
- What is the recommended pattern for parallel development on the same items?
Thank you for your support.
Looking forward to clarification from the Fabric product team or community experts.
Hello sahithibyreddy
This is not supported. Microsoft Fabric enforces a 1 workspace = 1 Git branch model.
To work with branches using Git integration, first connect the shared development team’s workspace to a single shared branch. For example, if your team uses one shared workspace, connect it to the main branch in your team’s repository, and sync between the workspace and the repo. If your team’s workflow has multiple shared branches like Dev/Test/Prod branches, each branch can be connected to a different workspace.
Please find details on branching and workspace integration here:
Git integration workspaces - Microsoft Fabric | Microsoft Learn
Hi sahithibyreddy,
You're going to want to use different workspaces for each developer, connected to their branches.
If your developers have permissions to create new workspaces, they can branch out to a new workspace which will create the workspace, connect it to git, and select their branch: Git integration workspaces - Microsoft Fabric | Microsoft Learn
Additionally, I would urge against a design where multiple developers are working on the same items at the same time, even in different branches. That will result in a merge conflict when you go to merge the feature branch back into dev.
Fabric Git integration works great for developers working in the same code base but on different items, as soon as they are working on the same items, it starts to fall apart a little bit.
Hope this helps
sahithibyreddy aha! I'm almost certain of what's happening to you, but I need to do a quick explain to do, remember that a git-enabled fabric workspace, has a "live" version (the one you see in the Fabric portal) and a "non-live" version, that is the items definition in the branch attached to the workspace. In order for your changes to go from your non-liver version to the the live version you need to do an updateFromGit operation (Update All button that appears when workspace detects changes coming from the branch) and to commit when the other way around.
But, I'm guessing you guys are working on the live version 👉 "Works on the same Fabric item (e.g., notebook) inside the same workspace" and, THIS IS THE MOST IMPORTANT PART... Notebook have this auto-save functionality, so, they are in a way, working on the same and that explains your observations.
The way to proper work in fabric is two, you create an isloated workspace attached to your developers feature branches, and once they ready with the code, merge back to the workspace's main branch 😁 so, you have one workspace that works as an integration hub of all your sandbox workspaces. A second commong alternative is to have each developer with it's designated sandbow workspace and continusly get the latest from the integration workspace to start a new feature cycle.
But I guess this is more an hypotesis than an answer, but I did answer the question on "What is the recommended pattern for parallel development on the same items?" In this article https://learn.microsoft.com/en-us/fabric/cicd/git-integration/manage-branches?tabs=azure-devops MSFT describes these patterns as Scenarios
1 - Develop using client tools, and Scenario 2 - Develop using another workspace
Hope this information helps, please let me know if it makes sense and my hyphotesis fits your observations 😉
4 Replies
- tayloramy
Super User
Hi sahithibyreddy,
You're going to want to use different workspaces for each developer, connected to their branches.
If your developers have permissions to create new workspaces, they can branch out to a new workspace which will create the workspace, connect it to git, and select their branch: Git integration workspaces - Microsoft Fabric | Microsoft Learn
Additionally, I would urge against a design where multiple developers are working on the same items at the same time, even in different branches. That will result in a merge conflict when you go to merge the feature branch back into dev.
Fabric Git integration works great for developers working in the same code base but on different items, as soon as they are working on the same items, it starts to fall apart a little bit.
Hope this helps
KevinChantAfter going through the issue, I agree that the "branch through to new workspace" feature has not been fully implemented and in my opinion the fix by tayloramy is the solution.
- deborshi_nag
Hello sahithibyreddy
This is not supported. Microsoft Fabric enforces a 1 workspace = 1 Git branch model.
To work with branches using Git integration, first connect the shared development team’s workspace to a single shared branch. For example, if your team uses one shared workspace, connect it to the main branch in your team’s repository, and sync between the workspace and the repo. If your team’s workflow has multiple shared branches like Dev/Test/Prod branches, each branch can be connected to a different workspace.
Please find details on branching and workspace integration here:
Git integration workspaces - Microsoft Fabric | Microsoft Learn
- svenchio
sahithibyreddy aha! I'm almost certain of what's happening to you, but I need to do a quick explain to do, remember that a git-enabled fabric workspace, has a "live" version (the one you see in the Fabric portal) and a "non-live" version, that is the items definition in the branch attached to the workspace. In order for your changes to go from your non-liver version to the the live version you need to do an updateFromGit operation (Update All button that appears when workspace detects changes coming from the branch) and to commit when the other way around.
But, I'm guessing you guys are working on the live version 👉 "Works on the same Fabric item (e.g., notebook) inside the same workspace" and, THIS IS THE MOST IMPORTANT PART... Notebook have this auto-save functionality, so, they are in a way, working on the same and that explains your observations.
The way to proper work in fabric is two, you create an isloated workspace attached to your developers feature branches, and once they ready with the code, merge back to the workspace's main branch 😁 so, you have one workspace that works as an integration hub of all your sandbox workspaces. A second commong alternative is to have each developer with it's designated sandbow workspace and continusly get the latest from the integration workspace to start a new feature cycle.
But I guess this is more an hypotesis than an answer, but I did answer the question on "What is the recommended pattern for parallel development on the same items?" In this article https://learn.microsoft.com/en-us/fabric/cicd/git-integration/manage-branches?tabs=azure-devops MSFT describes these patterns as Scenarios
1 - Develop using client tools, and Scenario 2 - Develop using another workspace
Hope this information helps, please let me know if it makes sense and my hyphotesis fits your observations 😉