Forum Discussion
Workspace Git integration
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
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 helping
MJParikhThank you for your feedback. This detailed post was greatly appreciated and will be reviewed thoroughly.
