Power BI Git Integration: What Really Happens When Two People Edit the Same Report

The Scenario: One Sales Report, Two Developers

You’re in a BI team supporting a regional sales organisation.

• Dataset: SalesModel in a shared workspace
• Report: Sales Performance.pbip (Git-connected workspace)
• Team:
  • Dev A focuses on visuals and layout
  • Dev B focuses on measures and model logic

On Monday morning:

1. Dev A wants to redesign the Executive Overview page.
2. Dev B wants to refactor a set of DAX measures used on the same page.

Both pull the latest from the main branch, both open the report in Power BI Service (or Desktop with Git), both start changing things.

At 11:00, Dev B saves and commits. At 11:10, Dev A tries to commit and suddenly sees conflicts.

Let’s unpack what’s actually happening.

How Power BI Git Integration Stores Your Report

When you connect a workspace to a Git repo and turn on “Store artifacts in Git”, a report is no longer just a .pbix blob.

A Power BI Project (.pbip) is a folder structure, typically like this:

Sales Performance
├─ Sales Performance.pbip
├─ definition.pbir            # Report definition (pages, visuals, layout)
├─ connections.json          # Dataset connection info
└─ semanticModel
   ├─ model.bim              # Tabular model (tables, relationships, measures)
   └─ partitions.json        # Partition definitions
``

Key points:

- **Report visuals and pages** live in `definition.pbir`.
- **Model, measures, relationships** live in `model.bim`.
- **Git** tracks these as plain text files (JSON / TOM-like).

So when two people “edit the same report”, they might be touching:

- The same file (e.g. both editing `definition.pbir`), or
- Different files (e.g. visuals vs measures) that Git can merge more safely.

---

## What “Editing the Same Report” Actually Means in Git Terms

Back to our scenario.

- Dev A:
  - Changes the layout of `Executive Overview`.
  - Renames a visual and updates its filters.
  - All of this lives in `definition.pbir`.

- Dev B:
  - Refactors `[Total Sales]` and `[Sales LY]` measures.
  - Adds `[Sales Growth %]`.
  - This lives in `semanticModel/model.bim`.

If they only touch those separate files, Git can usually auto-merge:

1. Dev B commits first.
2. Dev A pulls, gets Dev B’s changes.
3. Dev A’s local repo now has updated `model.bim` plus her own `definition.pbir` changes.
4. Dev A commits; Git sees different files changed and merges cleanly.

**Conflict risk is low** when:

- One person edits visuals only.
- Another edits measures/model only.

The trouble starts when both devs touch the same file.

---

## When Conflicts Happen: The Three Common Collision Points

### 1. Both Change the Same Measure

Dev A decides to tweak the tooltip measure `[Total Sales]` for a card visual.

Dev B is refactoring the same `[Total Sales]` measure for performance.

Under the hood, `model.bim` might have a block like this (simplified):

```json
{
  "name": "Total Sales",
  "expression": "CALCULATE(SUM('Sales'[Amount]))"
}

Dev B changes it to:

Total Sales = 
CALCULATE(
    SUM('Sales'[Amount]),
    KEEPFILTERS('Sales'[Status] <> "Cancelled")
)

Dev A changes it to:

Total Sales = 
VAR BaseSales = SUM('Sales'[Amount])
RETURN
    IF(BaseSales < 0, 0, BaseSales)

Both edits land in the same JSON node in model.bim. When the second developer pushes, Git sees a line-level conflict.

Result:

• Git marks the conflicting section with conflict markers.
• Power BI Service will not auto-resolve; you must fix the file then commit.

2. Both Change the Same Visual or Page

Dev A repositions a clustered column chart and changes its title.

Dev B edits the same chart’s field well (e.g. adds a legend field) while testing a new measure.

Internally, a visual in definition.pbir is a JSON object. Both devs update different properties of the same visual, but often within the same JSON block.

If their changes touch overlapping lines, Git can’t automatically decide which version to keep.

Result:

• Merge conflict in definition.pbir.
• You’ll see conflict markers inside a large JSON block representing the visual.

3. Both Change Structural Model Elements

Examples:

• Renaming the same table or column.
• Changing relationships between the same two tables.
• Changing row-level security roles.

These all live in model.bim. If two devs touch the same object, you get another text-level conflict.

How Conflicts Surface in Power BI Git Integration

Depending on your workflow, you’ll hit conflicts in slightly different places.

If You Use Power BI Service Git Integration

Typical flow:

1. You open a report in a Git-connected workspace.
2. You make changes and hit Save.
3. Power BI prompts you to Commit with a message.
4. If your branch is behind remote:
   • Power BI will try to pull and merge.
   • If merge fails, you see a conflict message.

The conflict resolution is not done in the visual editor. You need to:

• Pull the repo locally.
• Resolve conflicts in a Git client or code editor.
• Commit and push.

If You Use Desktop + Local Git Repo

Flow:

1. Clone the repo locally (e.g. git clone).
2. Open the .pbip in Power BI Desktop.
3. Make changes, save.
4. Run git pull before git push.

If someone else pushed changes:

• git pull tries to merge.
• Conflicts are flagged in files like model.bim or definition.pbir.
• You open them in VS Code or similar, resolve, then commit.

Conflict markers look like this:

<<<<<<< HEAD
  "expression": "Total Sales = VAR BaseSales = SUM('Sales'[Amount]) RETURN IF(BaseSales < 0, 0, BaseSales)"
=======
  "expression": "Total Sales = CALCULATE(SUM('Sales'[Amount]), KEEPFILTERS('Sales'[Status] <> \"Cancelled\"))"
>>>>>>> origin/main

You need to keep one version or manually combine them.

A Safe Team Workflow for Power BI + Git

The goal isn’t to avoid conflicts completely (that’s impossible in real teams), but to make them rare and easy to resolve.

Here’s a practical pattern for our Sales team.

1. Use Feature Branches, Not Direct Edits on main

For any non-trivial change:

1. Create a branch:

   git checkout -b feature/executive-overview-layout
   

2. Work on the branch.
3. Push and create a pull request.

Benefits:

• Conflicts surface in PRs, not while someone is trying to urgently hotfix production.
• You can review JSON diffs of model.bim and definition.pbir before merging.

2. Agree on “Ownership” Zones

Reduce overlapping edits by splitting responsibility:

• Dev A owns visuals and layout on Executive Overview.
• Dev B owns measures and model used by those visuals.

Practical rules:

• If you’re changing visuals, avoid editing measures in the same branch.
• If you’re changing measures, don’t tweak visuals just because you’re “already in there”. Leave that for a separate branch.

This keeps most changes in separate files (definition.pbir vs model.bim).

3. Pull Before You Edit, Not Just Before You Push

In our scenario, both devs pulled in the morning and then worked for hours.

Better habit:

• Always git pull (or sync in your Git client) before opening the .pbip to start a new change session.
• If you’ve been on a long call or meeting, pull again before continuing.

This keeps your local copy closer to the remote and reduces conflict scope.

4. Keep Commits Small and Focused

Compare these two commit styles:

• "Updated Executive Overview page" (includes layout, new measures, model changes).
• vs multiple commits:
  • "Added Sales Growth % measure"
  • "Updated Executive Overview layout"

Small, focused commits:

• Make conflicts easier to reason about.
• Allow partial cherry-picks if needed.

5. Use PR Reviews for Model Changes

Model changes (model.bim) can have wide impact.

For branches that touch the model:

• Require at least one peer review.
• In the PR, inspect the diff:
  • New measures
  • Changed expressions
  • Relationships and table renames

You can even copy DAX from the diff into Desktop to test.

How to Manually Resolve a Typical Conflict

Let’s walk a concrete resolution for our Sales team.

Situation:

• Dev B merged a branch that changed [Total Sales] measure.
• Dev A’s branch also changed [Total Sales].
• Dev A tries to merge and hits a conflict in model.bim.

Steps:

1. Open the conflicted file in a code editor (e.g. VS Code).
2. Locate the conflict markers around the [Total Sales] object.
3. Decide the final logic. Maybe you want both behaviours:

Total Sales = 
VAR BaseSales = 
    CALCULATE(
        SUM('Sales'[Amount]),
        KEEPFILTERS('Sales'[Status] <> "Cancelled")
    )
RETURN
    IF(BaseSales < 0, 0, BaseSales)

4. Replace the whole conflicted block with the combined expression.
5. Remove all <<<<<<<, =======, >>>>>>> lines.
6. Save, then run:

git add semanticModel/model.bim
git commit -m "Resolve conflict for Total Sales measure"

7. Re-open the .pbip in Desktop or Service to validate:
   • Check visuals using [Total Sales].
   • Run a quick sanity check on values.

This is tedious the first time, but once you’ve done it a few times it becomes routine.

When You Should Avoid Parallel Edits Entirely

There are still cases where parallel editing is more pain than it’s worth.

Consider locking or informal coordination when:

• You’re doing a large refactor of the model (renaming tables/columns, restructuring relationships).
• You’re rebuilding a core summary page used by many stakeholders.
• You’re migrating a report to a new dataset or semantic model.

Tactics:

• Use a team channel message: “I’m refactoring SalesModel today – please don’t touch measures in that model until tomorrow.”
• Put a short note in the repo README about ongoing work.

Git can help, but it can’t stop two people from stepping on each other if they coordinate poorly.

One Takeaway for Your Next Sprint

Before your next sprint, pick one important report and agree on a simple rule: visual changes and model changes must go through separate feature branches. That single habit drastically reduces painful merge conflicts when two people edit the same Power BI report and makes your Git history readable when you have to debug a broken metric three months from now.