New PBIR Format: Challenges with Git Noise ($schema and tabOrder)

[anotefler]

Hi everyone,

our team has in November transitioned to using the new PBIR format to improve our version control workflow. In our team we are using VS Code and GitLab. The company has a F256 capacity. So far we are happy but we are running into a recurring issue with some type of "Git noise" that makes code reviews and merges from time to time nearly impossible.

So what happens is that from time to time (not always) when a person saves the report it somehow triggers 1000+ file changes in the project repository, specifically the jsons in each folder of definition/pages/ * /visuals visual.json. These changes don't represent actual logic or design edits, but rather metadata shifts in almost every JSON file as can be seen below and in the picture. Even if we were only editing one tab in PBI, it suddenly affects also a lot of others which we didnt touch. We are also all on the exact same version of PowerBI: 2.150.2102.0 64-bit (Januar 2026). This occurs pretty randomly and we were not able to understand the cause or how to mitiaget this.

It happens for these two elements in the visual.json:

1. $schema: The schema URL in every visual container updates (e.g., from.../2.3.0/schema.jsonto.../2.4.0/schema.json\). This creates a diff for every single file in the report:

   // Example in visual.json:
   - "$schema": "https://.../visualContainer/2.3.0/schema.json"
   + "$schema": "https://.../visualContainer/2.4.0/schema.json"
   

2. tabOrder Re-indexing: Even though the visuals / layer order were not touched by us they somehow get recalculated for every visual. Again, this results in hundreds of "changes" that are irrelevant and not triggered by us. Sometimes the taborder also apprently somehow didnt exist.

   // Example in visual.json:
   - "tabOrder": 13000
   + "tabOrder": 12000
   
   // Example 2:
   -"width": 447.67568948630964
   +"width": 447.67568948630964,
   +"tabOrder": 22000

Problems:

• It is not clear what causes this, as it more or less randomly triggered. My suspicion was that this could be because before developing the data + schema was not refreshed but it also doesnt always trigger it

• This obviously makes merge requests unreadable and very problematic to find the true changes. Our approach was here to then just discard the latest changes and redo it but this is of course not a long time strategy

• In case merge conflicts occur this also creates additional complexity

Questions:

1. Did you also experience it? How are you guys managing Power BI Desktop version parity to prevent the $schema from bouncing back and forth? 

2. Has anyone successfully implemented Git attributes or Pre-commit hooks or similar to automatically "strip" or "standardize" these properties before pushing to the remote? Or are there any other solutions?

3. Could this be because how our gitattribute/gitignore is set up?

Our gitignore looks like this:

dashboards/**/.pbi/localSettings.json
dashboards/**/.pbi/cache.abf
**/SemanticModel/.pbi/cache.abf
**/SemanticModel/.pbi/unappliedChanges.json
# (optional) OS/editor
.DS_Store
Thumbs.db
.vscode/*.log

Our gitattributes like this:

# Use CRLF line endings (Windows style) because Power BI Desktop expects it.
* text=auto eol=crlf

# Explicitly mark binary files
*.png binary -text -diff -merge eol=unset
*.jpg binary -text -diff -merge eol=unset
*.jpeg binary -text -diff -merge eol=unset
*.gif binary -text -diff -merge eol=unset
*.svg binary -text -diff -merge eol=unset
*.ico binary -text -diff -merge eol=unset

# Ensure Power BI project files are treated as text (for diff/merge)
*.pbip text
*.tmdl text
*.json text
*.visual.json text
*.bim text

# Force UTF-8 encoding (without BOM)
*.pbip working-tree-encoding=UTF-8
*.tmdl working-tree-encoding=UTF-8
*.json working-tree-encoding=UTF-8
*.visual.json working-tree-encoding=UTF-8