Disadvantages of Using single GIT Repo per a PowerBI Workspace

[AshishKumarPBI]

Hi Mathias,

I am trying to implement Source control for my organization.
please review and confirm if my below understanding is correct.

In my organization, we have developers work on individual Thin Reports and datasets.
If I use single GIT Repo per Workspace basis, I assume it will create the issues with Pull requests and parallel changes.

For example, imagine the workspace has 5 thin reports and 3 datasets and I have created a single GIT Repo for this workspace.
Developer-1 works on one of the Power BI thin Report, Developer-2 works on Dataset and Developer-3 work on another thin Report.
If Developer-1 raises the Pull request, it will include the commits from other developers who are working on Other Dataset/reports.
The Pull request can't be merged Unless every developer changes are approved.
Even if Developer-1 changes are good to go and nothing to do with other developer's changes, he still need to wait for other developers to fix if any revisions required.

This wouldn't be good developer experience as multiple thin Reports and Datasets are individual Works and bringing them under single GIT Repo might lead to conflicts in collaborative environment and hinder parallel changes.

Please advise.

[jakeduddy]

A solution is to have a Group for the workspace and Subgroups for each of the entities {dataset 1, dataset 2, Report 1, Report 2..}. Then everything is grouped nicely but the diffs are isolated to a enitity. This is likely required in any case since you can deploy * for reports, but can only deploy singular datasets.

[andy-clapham]

If Developer-1 raises the Pull request, it will include the commits from other developers who are working on Other Dataset/reports.
The Pull request can't be merged Unless every developer changes are approved.

That sounds like all your developers are working on shared files, not on branches editable independently.

This is the problem git tries to solve - if you have a format that can be merged you can develop reports like any other complex software. e.g. using gitflow or something similar, with developers working on short lived branches dedicated to just their change, and merging them via PR back into the main branch.

Unfortunately It's not quite right for power bi yet, as the extract format is still not clean enough to do unified diff+merge (one day... sigh!) - and this is the $64000 question for pbi-tools.

But until that happy day, if you can organize the work so that developers aren't all working on different parts of the same report, you shouldn't need to merge too much.

[AshishKumarPBI]

A solution is to have a Group for the workspace and Subgroups for each of the entities {dataset 1, dataset 2, Report 1, Report 2..}. Then everything is grouped nicely but the diffs are isolated to a enitity. This is likely required in any case since you can deploy * for reports, but can only deploy singular datasets.

Yes. I agree. I believe we need to keep the Repo per each Dataset/Thin Report rather than at workspace. This way, we can version control and collaborate easily without stepping on others.

[AshishKumarPBI]

If Developer-1 raises the Pull request, it will include the commits from other developers who are working on Other Dataset/reports.
The Pull request can't be merged Unless every developer changes are approved.

That sounds like all your developers are working on shared files, not on branches editable independently.

This is the problem git tries to solve - if you have a format that can be merged you can develop reports like any other complex software. e.g. using gitflow or something similar, with developers working on short lived branches dedicated to just their change, and merging them via PR back into the main branch.

Unfortunately It's not quite right for power bi yet, as the extract format is still not clean enough to do unified diff+merge (one day... sigh!) - and this is the $64000 question for pbi-tools.

But until that happy day, if you can organize the work so that developers aren't all working on different parts of the same report, you shouldn't need to merge too much.

Hi @andy-clapham Thanks for the reply. Our developers are working on Branches. Not on Shared Files.
Also, I totally understand about the case of Developers working in different parts of same report.
But my concern here is , if we create a Repo per workspace, then even if the developers work on different thin reports (Under Same Workspace) will have this commit/PR issues. If One developer raises PR, it includes the commits from other developer from different thin report and PR can't be merged unless all the changes are reviewed/approved. So in this case, I assume the right way to do is to keep the Repo at Thin Report/Dataset Level. so we can keep things clean. Correct me if my understanding is wrong.

[andy-clapham]

Raising a PR will not include commits from other developers on other branches.
Those changes would have to be explicitly included in the commits on the PR's branch
- that's the part of your question I don't quite understand!

[turnersale]

We have a somewhat similar scenario in which we can have multiple BI devs working on a singular repo for what ultimately becomes a published app. We have built in layers of hierarchy so you can actually manage more than one app per repo. This would appear to be a big issue as you could get merge conflicts on the dev branch (this is where we do test deployments automatically), but what we have discovered is people don't work on the same report (thin or otherwise) at the same time. Thus the branches we make are usually short-lived and on a report that is unique to the task. This avoid having to elevate multiple commits, as you can merge to dev to test and merge (with approval of course) to main for production. Not sure if that helps in your scenario, but perhaps developing a work item/branch standard and allocating single devs to a report alteration would eliminate merging multiple commits.