Forum Discussion
Continued ContributorPBIP + Git with several report developers: how do you avoid merge conflicts?
Hi everyone,
We're moving a team of four report developers from shared PBIX files on SharePoint to Power BI Projects (PBIP) with TMDL and PBIR in Git. Single-developer work is great: readable diffs, proper history, PR reviews. But when two people touch the same project in parallel, things get messy, and I'd like to know how other teams have organized this.
Repo layout today
/Sales.SemanticModel/definition/
tables/*.tmdl <- one file per table, nice
relationships.tmdl <- everyone edits this one
model.tmdl
/Sales.Report/definition/
pages/<pageId>/page.json
pages/<pageId>/visuals/<visualId>/visual.json
report.json <- also touched by almost every changeWhat we're running into
- two branches add measures to the same table -> conflict in <table>.tmdl
- adding a relationship on both branches -> conflict in relationships.tmdl
- report.json / page ordering changes even when someone only edits one visual
- after resolving a conflict by hand, Desktop sometimes refuses to open the
project until the JSON/TMDL is fixed againQuestions
1. Do you split ownership, e.g. one person owns the semantic model and others only touch the report, or a thin report per developer connected live to a shared model?
2. Do you keep measures in a dedicated "_Measures" table (or several, per subject area) specifically to reduce conflicts in fact-table TMDL files?
3. Any conventions for branches and PR size? For example, short-lived feature branches merged daily vs. one branch per report page.
4. Are you using any tooling to validate a merged project before someone opens it in Desktop (Tabular Editor CLI, a schema check in CI, etc.)?
5. For PBIR specifically: is there a way to stop unrelated changes (page order, report-level settings) from showing up in every commit?
Curious to hear what has actually worked in a team setting. Thanks!
3 Replies
- Ritaf1983
Super User
Hi jubinsoni
Hi,
For a team of four developers, I would recommend a combination of clear ownership, smaller changes, and automated validation rather than relying on Git to resolve everything.
A few recommendations based on the issues you described:
- Separate semantic model and report responsibilities
I would establish clear ownership of structural model changes, particularly relationships, tables, and shared calculations.
This doesn't necessarily mean only one developer can modify the model, but changes to shared model objects should be coordinated and reviewed.
For report development, separate thin reports connected to a shared semantic model can help when developers are working on independent reporting areas. However, I wouldn't split a single report into several reports solely to avoid merge conflicts.
- Organize measures by subject area
I would prefer several dedicated measure tables (Sales, Finance, Operations, etc.) over one large _Measures table.
Since TMDL stores table definitions in separate files, this can reduce conflicts when developers work on different business areas.
It won't eliminate conflicts when two developers modify the same measure table, though.
- Keep feature branches short-lived
My recommendation would be:
- Create branches for specific features or tasks rather than entire report pages.
- Keep PRs small and focused.
- Regularly synchronize with the main branch.
- Avoid simultaneous changes to shared model objects and report-level settings whenever possible.
I would also include a review of the actual changed files before committing. Power BI Desktop can sometimes save metadata changes unrelated to the intended modification.
- Add validation before merging
At minimum, I would include:
- JSON syntax and schema validation for PBIR files.
- TMDL deserialization validation using TOM/TMDL APIs.
- Checks for accidental or unexpected changes to shared files.
- Opening and testing the merged project in Power BI Desktop before deployment.
Tabular Editor can also be useful for model validation and Best Practice Analyzer checks, but these should complement rather than replace PBIR validation.
- Minimize unnecessary PBIR changes
One detail worth checking: with the enhanced PBIR format, page ordering and the active page are stored in pages.json, while report.json contains report-level metadata.
There isn't a setting that guarantees unrelated metadata will never be saved.
I would avoid changing page order and report-level settings during parallel development, and review unexpected changes to shared files before committing them.
My main recommendation: Treat PBIP as source-controlled development, but organize collaboration around ownership of shared objects. TMDL and PBIR reduce the number of conflicts; they don't eliminate the need to coordinate changes.
For four developers, I would start with these relatively simple conventions before introducing a more complicated branching or repository structure.
- If this post helps, then please consider Accepting it as the solution to help the other members find it more quickly.
- Shai_Karmani
We moved four devs onto PBIP about a year ago and hit all of these. The pattern that stuck was ownership-based: keep the semantic model in its own folder with a single owner (CODEOWNERS), and have report developers build thin reports that live-connect to the published model so they never touch TMDL at all.
Inside the model, put every measure into dedicated "_Measures" tables, one per subject area. Since TMDL writes one file per table, two people adding measures almost never collide on the fact-table TMDL files.
Keep branches short-lived and PRs small (one page, one measure group, or one relationship per PR), merged daily. Run Tabular Editor 3 CLI against the TMDL on every PR to catch syntax issues before anyone opens the project in Desktop.
For report-side PBIR noise, standardize Desktop version and PBIP settings across the team and keep PRs tiny; Microsoft is still iterating on the format.
If this helped, a thumbs up and accepting the solution would be appreciated.
Best regards,
Shai Karmani - Prince0011
Memorable Member
Hi,
I always prefer to follow a simple concept that resolve most of the conflicts easily ,I would suggest you to consider given ideas, and let me know if u have some doubts.
1 . What worked for us was splitting ownership: one person owns the semantic model, and the other developers build thin reports live-connected to it. That removes most model conflicts, including relationships'.
2 . Measures go in per-subject-area tables like _Sales and _Finance, so two people rarely edit the same file. Keep branches short-lived and merge daily, one report page per branch.
3 . In CI, run Tabular Editor CLI or a TMDL parse check on every PR, so a bad merge fails before anyone opens Desktop.
4 . For report. Json noise, I haven’t found a clean fix. Reviewing only the files that changed on a page helps.
If this helped, feel free to give it a kudos or mark it as solution, helps others find it too.
