Forum Discussion

bao_phan's avatar
bao_phan
Advocate II
5 days ago

Multiple developers working on the same Fabric item

Hi everyone,

I’m looking for some advice on the best way in Microsoft Fabric when multiple developers need to work on the same item, such as a Pipeline, Notebook, or other Fabric artifact.

For example, we have 2 devs working on the same notebook at the same time. Each developer may make changes to different parts of the item, and eventually we need to combine those changes and deploy the final version.

I’m wondering how do you normally handle multiple developers working on the same Fabric item?

I read Microsoft Docs and know that they advise to create seperate workspace for each dev (acting as branch like we have in Git). Beside that options, do we have anything else ?

Thanks!

3 Replies

  • ShivekMaharaj's avatar
    ShivekMaharaj
    Impactful Individual

    Hi bao_phan​,

    I would separate this into two collaboration scenarios.

    For Notebooks specifically, Fabric actually supports real-time coediting, so two developers can open and edit the same notebook simultaneously. That works well for pair programming or jointly working on the same artifact, but it is still one shared live notebook rather than two isolated versions that you later merge.

    If the developers need independent changes, code review and a controlled merge, I would still use Git branches with isolated development environments. Microsoft's current development process guidance recommends a separate runtime environment because a Fabric workspace is shared and can only be connected to one branch at a time.

    One newer option worth looking at is the Branched workspace experience, currently in Preview. A developer can branch out from the source workspace into their own Git branch and workspace, make the changes there, then merge through the normal Git/PR process. Selective branch-out is also in Preview, so you can choose only the items needed for that developer rather than necessarily branching the entire workspace.

    For notebooks, another option is local development through VS Code. Microsoft also lists client-tool development as an alternative to giving every developer a permanent workspace, with a Fabric workspace only needed when the change needs to be tested in the service.

    So I would use coediting when the developers intentionally want to work together on the same notebook, and branches when the work needs to be developed and reviewed independently.

    AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.

  • v-achippa's avatar
    v-achippa
    Community Support

    Hi bao_phan​,

    Thank you for reaching out to Microsoft Fabric Community.

    Thank youRupa01​ShivekMaharaj​Rupa01​for the prompt response.

    As we haven’t heard back from you, we wanted to kindly follow up to check if the solution provided by the user for the issue worked?  or let us know if you need any further assistance.

    Thanks and regards,
    Anjan Kumar Chippa

  • Hi bao_phan​ 

    Recommended approach

    • Use Git integration for collaborative development where supported. Each developer works in their own branch, commits changes, and uses pull requests to merge changes.
    • Avoid having multiple developers directly edit the same item simultaneously. Fabric doesn't provide the same fine-grained real-time collaborative editing experience for every item type.
    • Use separate workspaces for development when practical:
      • Developer A → Dev workspace/branch
      • Developer B → Dev workspace/branch
      • Shared/Test workspace → integrated changes
      • Production workspace → approved releases
    • Resolve Git conflicts carefully. This is particularly important for Fabric items whose definitions are stored as files and can be modified by multiple people.
    • For notebooks, multiple people can collaborate more naturally, but Git/branching is still preferable for controlled development and deployment.
    • For semantic models and other shared artifacts, establish ownership and a change/merge process so that one developer doesn't unintentionally overwrite another's changes.

    A typical team workflow is:

    Please let me know if you need any additional details.

    Thanks,

    Jitendra