Locking binary files using git version control system

Question

For one and a half years, I have been keeping my eyes on the git community in hopes of making the switch away from SVN. One particular issue holding me back is the inabilit

Answer 1

When I was using Subversion, I religiously set the svn:needs-lock property on all binary and even the hard-to-edit text files. I never actually experienced any conflicts.

Now, in Git, I don't worry about such things. Remember: locks in Subversion aren't actually mandatory locks, they are merely communication tools. And guess what: I don't need Subversion to communicate, I can manage just fine with E-Mail, Phone and IM.

Another thing I did, is to replace many binary formats with plain text formats. I use reStructuredText or LaΤ_ΕΧ instead of Word, CSV instead of Excel, ASCII-Art instead of Visio, YAML instead of databases, SVG instead of OO Draw, abc instead of MIDI, and so on.

Answer 2

Git LFS 2.0 has added support for file locking.

With Git LFS 2.0.0 you can now lock files that you're actively working on, preventing others from pushing to the Git LFS server until you unlock the files again.

This will prevent merge conflicts as well as lost work on non-mergeable files at the filesystem level. While it may seem to contradict the distributed and parallel nature of Git, file locking is an important part of many software development workflows—particularly for larger teams working with binary assets.

Answer 3

In response to Mario's additional concern with changes happening in multiple places on the binaries. So the scenario is Alice and Bob are both making changes to the same binary resource at the same time. They each have their own local repo, cloned from one central remote.

This is indeed a potential problem. So Alice finishes first and pushes to the central alice/update branch. Normally when this happens, Alice would make an announcement that it should be reviewed. Bob sees that and reviews it. He can either (1) incorporate those changes himself into his version (branching from alice/update and making his changes to that) or (2) publish his own changes to bob/update. Again, he makes an announcement.

Now, if Alice pushes to master instead, Bob has a dilemma when he pulls master and tries to merge into his local branch. His conflicts with Alice's. But again, the same procedure can apply, just on different branches. And even if Bob ignores all the warnings and commits over Alice's, it's always possible to pull out Alice's commit to fix things. This becomes simply a communication issue.

Since (AFAIK) the Subversion locks are just advisory, an e-mail or instant message could serve the same purpose. But even if you don't do that, Git lets you fix it.

No, there's no locking mechanism per se. But a locking mechanism tends to just be a substitute for good communication. I believe that's why the Git developers haven't added a locking mechanism.

Answer 4

I have discussed this issue on git discussion groups and have concluded that at this time, there is no agreed upon method of centralized file locking for git.

Answer 5

Git is not providing any command to lock files but I've fund a way to achieve that function using git hooks. An auxiliary server is needed to store the lock informations. We can use a pre-commit hook to check if any of the committed files is locked. And if anyone locks a file, a program should tell the auxiliary server the information of the locker and the locked file.