-1

Our team will start to use Git in order to manage binary PowerBi report files. Since the files are binary, two files cannot easily be merged.

Does this mean that if two users work on the same report at the same time, one of the users will push their updated report file to the remote repo first, and the second user will have to discard their changes and start over?

We have previously used Microsoft Team foundation where there is an option to "Disable shared Checkout"- which means that only one person at a time can check out and edit a file.

Is anything similar possible with Git? To me it seems to be contradictive to the distributed nature of Git.

Any ideas how we best deal with this problem when using Git?

Biffen
  • 6,249
  • 6
  • 28
  • 36
Henrik af forselles
  • 1
  • 4
    If PowerBI can't save reports in any other formats, it's time to find a new tool. – choroba Nov 12 '21 at 10:55
  • 2
    Does this answer your question? [Is there a way to lock individual files or directories on fork when using git?](https://stackoverflow.com/questions/13662255/is-there-a-way-to-lock-individual-files-or-directories-on-fork-when-using-git) – Joe Nov 12 '21 at 10:55

2 Answers2

1

Unfortunately, opaque binary files are not well-suited to collaborative editing.

I've seen this in the context of 3D CAD-files. Most of the revision control packages in that space only allow one single user at a time to check-out a file for modification.

Git (and other distributed RCS) don't work like that. That means that when using git basically the first to push wins, and the rest will have to pull from upstream and redo their work.

It seems that in this case, a centralized revision control system is more appropriate.

Roland Smith
  • 42,427
  • 3
  • 64
  • 94
-2

You could leverage Git-branching methodology to not completely freeze the remote branch check-in. For instance, you could enforce contributors to create a PR from their forked repositories.

Then some authority persons can pick which binary version is good to be merged, or you have a nice GitHub action with a GitHub bot account which runs test on the binary files and write back on to the PR about the quality of files.

SIDE NOTE -- You could consider using Git LFS, instead of a pure Git repository, because such a binary stored repository can easily reach to uncontrollable size repository. The growth is incremental and the time it takes to clone repository will be slower and slower.

Junji Shimagaki
  • 286
  • 2
  • 9