Forum Discussion
Workspace Git integration
what’s the better approach for a team of around 10 developers?
For context, would it be better to have a shared sandbox workspace where all developers collaborate before deploying to dev/test? I’m concerned this might lead to branch collisions or merge conflicts, especially if multiple developers are working on the same notebook.
Alternatively, is it better for each developer to have an isolated workspace where they can create and manage their own branches?
Curious to hear your thoughts on the trade-offs.
The end goal is to build a CI/CD pipeline with this architecture:
Sand box workspace -> Dev ->Test -> Production
The sandbox workspace will include shortcuts to the development, test, and production environments. CI/CD processes will utilize Azure DevOps tools and deployment pipelines."
Hi Jhermytheone
we recently released the branched workspaces, selective branching features, which aim to tackle the development process (CI) to enhance the developer experience, work only on what is needed and imporve the the time to code.
You can read more about it in this blog: https://community.fabric.microsoft.com/t5/Fabric-Updates-Blogs/Introducing-new-Git-developer-experiences-in-Microsoft-Fabric/ba-p/5172181
and our documentation: https://learn.microsoft.com/en-us/fabric/cicd/git-integration/branched-workspace
9 Replies
Hi Jhermytheone,
Per-developer isolated workspaces win for a team of 10. A shared sandbox invites merge conflicts, especially when multiple people edit the same notebook simultaneously.Why Shared Sandboxes Break Down
The Fabric workspace is a live environment. Any change made directly in a shared workspace overrides and immediately affects all other users. With 10 developers, that means a teammate editing a notebook while you are working on it will overwrite your changes without warning. Branch collisions become a regular problem, not an edge case.
Recommended Architecture
I have seen large organizations follow setups like the below, but this depends on budget and fabric licensing.
- Each developer gets their own isolated workspace connected to their own feature or working branch in Git.
- Developers reconnect their workspace to a new branch when starting new tasks.
- A dedicated dev workspace connects to the shared dev or main branch, locked from direct pushes; changes only enter via pull requests.
- Test and production workspaces are separate, locked-down environments promoted via Fabric deployment pipelines or Azure DevOps, not manual branch switches.
Branching Policy Matters
The dev, test, and prod branches should have policies preventing direct commits. Only approved PRs can merge into these branches. This enforces code review and keeps your Sandbox > Dev > Test > Production pipeline clean and auditable.
Where the Sandbox Fits
Your "sandbox" workspace in the architecture is best thought of as a shared shortcuts layer, giving developers quick read access to Dev/Test/Prod data without write access to those environments. It is not a place where developers actively commit code.
Example Setup for 10 Devs
Layer
Workspace
Git Branch
Who Writes
Sandbox
Shared, read-oriented
None or main (read)
No direct writes
Dev
Shared, locked
dev branch (PR only)
PRs from feature branches
Individual
Per-developer workspace
Personal feature branches
Each developer
Test
Dedicated
release or test branch
Deployment pipeline
Prod
Dedicated
main (PR only)
Deployment pipeline
Automation helps at scale. If creating 10 workspaces manually is a governance concern, you can script workspace and branch creation using the Fabric REST API or the fabric-cicd Python library, then wire everything to Azure DevOps pipelines. That keeps onboarding new developers consistent and repeatable.
Thank you!
Proud to be a Super User!
📩 Need more help?
✔️ Don’t forget to Accept as Solution if this guidance worked for you.
💛 Your Like motivates me to keep helpingMJParikhThank you for your feedback. This detailed post was greatly appreciated and will be reviewed thoroughly.
Hi Jhermytheone
we recently released the branched workspaces, selective branching features, which aim to tackle the development process (CI) to enhance the developer experience, work only on what is needed and imporve the the time to code.
You can read more about it in this blog: https://community.fabric.microsoft.com/t5/Fabric-Updates-Blogs/Introducing-new-Git-developer-experiences-in-Microsoft-Fabric/ba-p/5172181
and our documentation: https://learn.microsoft.com/en-us/fabric/cicd/git-integration/branched-workspace
yaronprigal Thank you
Microsoft recommends a development process where you would create your sandbox (feature) workspaces for developers and then merge them to your Dev workspace.
https://learn.microsoft.com/en-us/fabric/cicd/manage-deployment#development-process
Faster merges and being vigilant with Pull Requests will help reduce merge conflicts.How you create these workspaces depends on your environment. If the Team all has permissions to create new workspaces they can do s from the GUI. Alternatively, you can look to implement the branch out to new workspace scripts provided by Microsoft whilst waiting for the new branching out method to appear:
https://github.com/microsoft/fabric-toolbox/tree/main/accelerators/CICD/Branch-out-to-new-workspace
I hope this helps...KevinChant Thank you
Hi Jhermytheone
I wanted to check if you had the opportunity to review the information provided. Please feel free to contact us if you have any further questions.
Thank you.I am currently reviewing and will definitely reach out if further questions arise. Thank you
Hi Jhermytheone
May I check if this issue has been resolved? If not, Please feel free to contact us if you have any further questions.
Thank you
