Forum Discussion
Concurrent Git Branching in Fabric Workarounds for Data Rehydration?
Hi Fabric Community,
We're looking for recommendations on Git branching strategies for multi-developer teams in Fabric.
The Challenge:
- In Synapse, developer branch selection was independent per user.
- In Fabric, changing the workspace Git branch alters the branch for all users in that workspace, making concurrent development on separate branches difficult.
Current Workaround & Pain Point:
- Fabric documentation recommends creating a new workspace per feature branch.
- Issue: Rehydrating data for every feature workspace is time-consuming and something we want to avoid.
Questions:
- What is the recommended best practice for isolated concurrent feature branching in Fabric?
- Are there established patterns (e.g., using shortcuts, thin reports, or shared lakehouses across dev workspaces) to avoid rehydrating data for each feature workspace?
Appreciate any insights!
For isolated feature branches without rehydrating data, the pattern most teams land on in Fabric is OneLake shortcuts.
Keep a single central lakehouse (in a shared dev or platform workspace) that holds the actual Bronze/Silver data. Create your feature workspace per branch as the docs recommend, but inside it create a lakehouse whose Tables and Files are OneLake shortcuts pointing back to that central lakehouse. Notebooks, pipelines, and semantic models in the feature branch then read the same underlying Delta tables with zero data copy, and only the items you actually change get committed to the feature branch.
A few practical notes. Shortcuts are not versioned as Git artifacts, so treat the central lakehouse as shared infrastructure and Git-source the compute and model items only. For anything the branch needs to write in isolation (a new Silver or Gold output), point those writes at a workspace-local lakehouse so branches do not collide on the same Delta path. Thin semantic models on top of a shared lakehouse behave the same way and avoid duplicating the model itself across workspaces.
If this helped, a thumbs up and marking it as the accepted solution would be appreciated.
Best,
Shai Karmani
5 Replies
- Shai_Karmani
Super User
For isolated feature branches without rehydrating data, the pattern most teams land on in Fabric is OneLake shortcuts.
Keep a single central lakehouse (in a shared dev or platform workspace) that holds the actual Bronze/Silver data. Create your feature workspace per branch as the docs recommend, but inside it create a lakehouse whose Tables and Files are OneLake shortcuts pointing back to that central lakehouse. Notebooks, pipelines, and semantic models in the feature branch then read the same underlying Delta tables with zero data copy, and only the items you actually change get committed to the feature branch.
A few practical notes. Shortcuts are not versioned as Git artifacts, so treat the central lakehouse as shared infrastructure and Git-source the compute and model items only. For anything the branch needs to write in isolation (a new Silver or Gold output), point those writes at a workspace-local lakehouse so branches do not collide on the same Delta path. Thin semantic models on top of a shared lakehouse behave the same way and avoid duplicating the model itself across workspaces.
If this helped, a thumbs up and marking it as the accepted solution would be appreciated.
Best,
Shai Karmani
v-achippaCommunity Support
Hi johanesc,
Thank you for reaching out to Microsoft Fabric Community.
Thank you Shai_Karmani and ShivekMaharaj for the prompt response.
As we haven’t heard back from you, we wanted to kindly follow up to check if the response provided by the user's for the issue worked? or let us know if you need any further assistance.
Thanks and regards,
Anjan Kumar Chippa
KevinChantHow many developers are in your team as independent developer workspaces instead of feature workspaces is also a viable option depending on your way of working.
Which is where each developer has their own workspace and branches out from your dev (or other) branch into their workspace each time they start working on a new feature. Saving the effort required to branch out to a new feature workspace each time and removing the requirement to give them all permissions to create new workspaces.- ShivekMaharaj
Community Champion
Hi johanesc,
Shai's shared-data pattern is a good way to avoid rehydrating the same development data for every branch. I'd add a couple of current Fabric details that make the pattern even more useful.
For the Git side, Microsoft's development guidance confirms that a Fabric workspace is a shared runtime environment and can only be connected to one branch at a time. So for true concurrent feature development, separate developer/feature workspaces are still the recommended isolation boundary.
The newer Branched Workspace experience, currently in Preview, helps automate that branch + workspace pattern. It also supports selective branching, so you can initially bring only the Fabric items needed for that feature into the new workspace rather than reproducing everything.
For the data plane, I like the idea of keeping a stable shared development Lakehouse and letting feature workspaces consume common input data through OneLake shortcuts. That gives you zero-copy access while keeping the runtime/Git workspaces isolated.
One small update to the point about shortcut versioning: current Lakehouse Git/ALM documentation now says OneLake shortcut definitions are tracked in Git as GA metadata, stored in shortcuts.metadata.json. The underlying Delta tables/files still aren't versioned or copied by Git, but the shortcut definitions themselves can now participate in the CI/CD lifecycle.
I'd therefore use the shared Lakehouse mainly for stable/read-oriented development inputs. If a feature needs to change ingestion or write its own state, I'd keep those outputs local to that feature workspace so the branches don't start interfering through the shared data layer.
So my preferred pattern would be:
Branched workspace per developer/feature + selective branching for item isolation + shared OneLake data through shortcuts where the data can safely remain common + feature-local outputs where true data isolation is needed.
AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.
