Forum Discussion

powerbiexpert22's avatar
powerbiexpert22
Icon for Impactful Individual rankImpactful Individual
18 days ago
Solved

pbix version control in fabric

one of the workspace is hosted on fabric capacity, i want to use version control , what are the options available in fabric for version control?

Need Help
power bi
  • jubinsoni's avatar
    jubinsoni
    17 days ago

    Hi powerbiexpert22​,

    To add the practical "how do I actually start" part on top of the options above, this is the setup I'd use for a single Fabric workspace:

    1. tenant admin: enable "Users can synchronize workspace items with
   their Git repositories" (and GitHub, if you use GitHub)
2. create a repo (Azure DevOps or GitHub) with a main branch
3. workspace settings -> Git integration -> connect repo / branch / folder
   -> the first commit exports your reports + models as PBIP-style folders
4. Desktop: clone the repo locally -> open the .pbip -> edit -> save
   -> git commit + push
5. workspace -> Source control -> Update all
   (or edit in the Service and Commit from the same pane)

    Day-to-day, the important rule is to pick one direction per change: either edit in Desktop and push, or edit in the Service and commit. Editing the same report in both places before syncing is what produces conflicts.

    Two common gotchas:

    existing PBIX files: open each in Desktop -> File -> Save as -> Power BI Project
  (or let the first workspace commit export them), then work only from the repo
large models: keep data out of Git
  -> the .pbip stores definitions only; the cache.abf is gitignored by default

    Once that works, a second workspace (Dev) connected to a feature branch, plus a deployment pipeline to Test/Prod, gives you the full flow without changing how the report itself is built.

    So my overall approach would be:

    enable Git tenant setting -> connect workspace to a repo branch
-> convert PBIX to PBIP -> edit in Desktop, commit, Update in Service
-> later: Dev workspace on a branch + deployment pipeline to Prod

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

4 Replies

  • ShivekMaharaj's avatar
    ShivekMaharaj
    Icon for Community Champion rankCommunity Champion
    16 days ago

    Hi powerbiexpert22​,

    The replies above cover the main options well.

    One small clarification is that for proper source control I would think in terms of PBIP/Fabric item definitions rather than versioning the PBIX binary itself.

    Microsoft’s Power BI Desktop Projects guidance describes PBIP as the source-control-friendly project format, where the report and semantic model are stored as separate text-based files that Git can track and compare.

    If you connect the Fabric workspace directly to Git, the workspace itself can synchronize supported report and semantic model definitions with Azure DevOps or GitHub through Fabric Git integration.

    Also note that you may not see a .pbip file in the repository when using workspace Git integration. Microsoft documents that the .pbip file is optional; the report and semantic model folders contain the actual definitions, and the report can be opened from definition.pbir.

    So my preference would be:

    PBIP / Fabric item definitions for source control
→ Git branch/repository for version history and collaboration
→ deployment pipeline or CI/CD process for promotion between Dev/Test/Prod

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

  • ShahRukhSameer's avatar
    ShahRukhSameer
    Icon for Solution Sage rankSolution Sage
    18 days ago

    Hi powerbiexpert22​,

    If your workspace is on Fabric capacity, you can use Git integration for version control, but the best approach depends on how you manage your Power BI reports.

    You have a few options:

    1. Fabric Git integration: Connect your workspace to Azure DevOps or GitHub to track changes and manage versions for supported items.
    2. PBIP format: Save your Power BI reports as Power BI Project files instead of PBIX. The report and model definitions are stored as files, making it easier to track changes and compare versions through Git.
    3. Deployment pipelines: Useful for moving reports between Dev, UAT, and Prod, but they don't replace Git version control.
    4. PBIX backups: You can keep copies in SharePoint or Azure DevOps, but comparing changes between versions is more difficult.

    Personally, I'd recommend PBIP with Azure DevOps or GitHub. Just check that your items are supported by Git integration and that the required workspace and tenant settings are enabled.

    Documentation: https://learn.microsoft.com/en-us/fabric/cicd/git-integration/intro-to-git-integration

    https://learn.microsoft.com/en-us/power-bi/developer/projects/projects-overview

  • jubinsoni's avatar
    jubinsoni
    Icon for Memorable Member rankMemorable Member
    17 days ago

    Hi powerbiexpert22​,

    To add the practical "how do I actually start" part on top of the options above, this is the setup I'd use for a single Fabric workspace:

    1. tenant admin: enable "Users can synchronize workspace items with
   their Git repositories" (and GitHub, if you use GitHub)
2. create a repo (Azure DevOps or GitHub) with a main branch
3. workspace settings -> Git integration -> connect repo / branch / folder
   -> the first commit exports your reports + models as PBIP-style folders
4. Desktop: clone the repo locally -> open the .pbip -> edit -> save
   -> git commit + push
5. workspace -> Source control -> Update all
   (or edit in the Service and Commit from the same pane)

    Day-to-day, the important rule is to pick one direction per change: either edit in Desktop and push, or edit in the Service and commit. Editing the same report in both places before syncing is what produces conflicts.

    Two common gotchas:

    existing PBIX files: open each in Desktop -> File -> Save as -> Power BI Project
  (or let the first workspace commit export them), then work only from the repo
large models: keep data out of Git
  -> the .pbip stores definitions only; the cache.abf is gitignored by default

    Once that works, a second workspace (Dev) connected to a feature branch, plus a deployment pipeline to Test/Prod, gives you the full flow without changing how the report itself is built.

    So my overall approach would be:

    enable Git tenant setting -> connect workspace to a repo branch
-> convert PBIX to PBIP -> edit in Desktop, commit, Update in Service
-> later: Dev workspace on a branch + deployment pipeline to Prod

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

  • v-aatheeque's avatar
    v-aatheeque
    Icon for Community Support rankCommunity Support
    15 days ago

    Hi powerbiexpert22​ 

    Have you had a chance to look through the responses shared earlier? If anything is still unclear, we’ll be happy to provide additional support.