使用 git 版本控制系统锁定二进制文件

Locking binary files using git version control system

提问by Mario

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 inability to lock binary files. Throughout the past year I have yet to see developments on this issue. I understand that locking files goes against the fundamental principles of distributed source control, but I don't see how a web development company can take advantage of git to track source code and image file changes when there is the potential for binary file conflicts.

一年半以来，我一直关注 git 社区，希望能够摆脱 SVN。阻碍我的一个特殊问题是无法锁定二进制文件。在过去的一年里，我还没有看到这个问题的进展。我知道锁定文件违反了分布式源代码控制的基本原则，但我不知道 Web 开发公司如何在可能发生二进制文件冲突时利用 git 来跟踪源代码和图像文件的更改。

To achieve the effects of locking, a "central" repository must be identified. Regardless of the distributed nature of git, most companies will have a "central" repository for a software project. We should be able to mark a file as requiring a lock from the governing git repository at a specified address. Perhaps this is made difficult because git tracks file contents not files?

为了实现锁定的效果，必须确定一个“中央”存储库。不管 git 的分布式特性如何，大多数公司都会有一个软件项目的“中央”存储库。我们应该能够将文件标记为需要来自指定地址的管理 git 存储库的锁定。也许这很困难，因为 git 跟踪文件内容而不是文件？

Do any of you have experience in dealing with git and binary files that should be locked before modification?

大家有没有处理过修改前应该锁定的git和二进制文件？

NOTE: It looks like Source Gear's new open source distributed version control project, Veracity, has locking as one of its goals.

注意：看起来 Source Gear 的新开源分布式版本控制项目 Veracity 将锁定作为其目标之一。

采纳答案by osowskit

Git LFS 2.0has added support for file locking.

Git LFS 2.0添加了对文件锁定的支持。

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.

使用 Git LFS 2.0.0，您现在可以锁定您正在处理的文件，防止其他人推送到 Git LFS 服务器，直到您再次解锁文件。

这将防止合并冲突以及在文件系统级别对不可合并文件的工作丢失。虽然它似乎与 Git 的分布式和并行特性相矛盾，但文件锁定是许多软件开发工作流程的重要组成部分，尤其是对于使用二进制资产的大型团队而言。

回答by Craig McQueen

Subversion has locks, and they aren't just advisory. They can be enforced using the svn:needs-lockattribute (but can also be deliberately broken if necessary). It's the right solution for managing non-mergeable files. The company I work for stores just about everything in Subversion, and uses svn:needs-lockfor all non-mergeable files.

Subversion 有锁，而且它们不仅仅是建议性的。它们可以使用svn:needs-lock属性来强制执行（但也可以在必要时故意破坏）。这是管理不可合并文件的正确解决方案。我工作的公司几乎存储了 Subversion 中的所有内容，并svn:needs-lock用于所有不可合并的文件。

I disagree with "locks are just a communication method". They are a much more effective method than push-notifications such as phone or e-mail. Subversion locks are self-documenting (who has the lock). On the other hand, if you have to communicate by other traditional push-notification channels, such as e-mail, who do you send the notification to? You don't know in advance who might want to edit the file, especially on open-source projects, unless you have a complete list of your entire development team. So those traditional communication methods aren't nearly as effective.

我不同意“锁只是一种交流方式”。它们是比电话或电子邮件等推送通知更有效的方法。Subversion 锁是自我记录的（谁拥有锁）。另一方面，如果您必须通过其他传统的推送通知渠道（例如电子邮件）进行通信，您会将通知发送给谁？您事先不知道谁可能想要编辑该文件，尤其是在开源项目中，除非您拥有整个开发团队的完整列​​表。所以那些传统的沟通方法几乎没有那么有效。

A central lock server, while against the principles of DVCS, is the only feasible method for non-mergeable files. As long as DVCS don't have a central lock feature, I think it will keep the company I work for using Subversion.

中央锁服务器，虽然违反了 DVCS 的原则，但对于不可合并的文件，这是唯一可行的方法。只要 DVCS 没有中央锁定功能，我认为它会让我工作的公司继续使用 Subversion。

The better solution would be to make a merge tool for all your binary file formats, but that's a longer-term and ongoing goal that will never be "finished".

更好的解决方案是为所有二进制文件格式制作一个合并工具，但这是一个永远不会“完成”的长期和持续目标。

Here's an interesting read on the topic.

这是有关该主题的有趣读物。

回答by Greg Hewgill

I agree that locking binary files is a necessary feature for some environments. I just had a thought about how to implement this, though:

我同意锁定二进制文件是某些环境的必要功能。不过，我只是想过如何实现这一点：

• Have a way of marking a file as "needs-lock" (like the "svn:needs-lock" property).
• On checkout, git would mark such a file as read-only.
• A new command git-lockwould contact a central lock server running somewhere to ask permission to lock.
• If the lock server grants permission, mark the file read-write.
• git-addwould inform the lock server of the content hash of the locked file.
• The lock server would watch for that content hash to appear in a commit on the master repository.
• When the hash appears, release the lock.

• 有一种方法可以将文件标记为“needs-lock”（如“svn:needs-lock”属性）。
• 在结帐时，git 会将此类文件标记为只读。
• 一个新的命令git-lock会联系运行在某处的中央锁服务器来请求锁定权限。
• 如果锁服务器授予权限，则将文件标记为读写。
• git-add将通知锁定服务器锁定文件的内容哈希。
• 锁定服务器将监视该内容哈希是否出现在主存储库的提交中。
• 当哈希出现时，释放锁。

This is very much a half-baked idea and there are potential holes everywhere. It also goes against the spirit of git, yet it can certainly be useful in some contexts.

这是一个非常不成熟的想法，到处都有潜在的漏洞。它也违背了 git 的精神，但它在某些情况下肯定是有用的。

Within a particular organisation, this sort of thing could perhaps be built using a suitable combination of script wrappers and commit hooks.

在一个特定的组织中，这种事情也许可以使用脚本包装器和提交钩子的合适组合来构建。

回答by Michael Johnson

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.

为了回应马里奥对二进制文件多个地方发生的变化的额外关注。所以场景是 Alice 和 Bob 同时对同一个二进制资源进行更改。他们每个人都有自己的本地仓库，从一个中央远程克隆。

This is indeed a potential problem. So Alice finishes first and pushes to the central alice/updatebranch. 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/updateand making his changes to that) or (2) publish his own changes to bob/update. Again, he makes an announcement.

这确实是一个潜在的问题。所以爱丽丝首先完成并推送到中央alice/update分支。通常，当这种情况发生时，Alice 会宣布应该对其进行。鲍勃看到并它。他可以 (1) 自己将这些更改合并到他的版本中（从alice/update那个版本开始并对其进行更改）或 (2) 将他自己的更改发布到bob/update. 再一次，他宣布了一个消息。

Now, if Alice pushes to masterinstead, Bob has a dilemma when he pulls masterand 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.

现在，如果 Alice 改为masterpush ，Bob 在 pullmaster并尝试合并到他的本地分支时会遇到两难的境地。他与爱丽丝的冲突。但同样，同样的程序可以应用，只是在不同的分支上。即使 Bob 忽略了所有警告并提交了 Alice 的提交，也总是可以取消 Alice 的提交来修复问题。这只是一个沟通问题。

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.

由于（AFAIK）Subversion 锁只是建议性的，因此电子邮件或即时消息可以达到相同的目的。但即使您不这样做，Git 也可以让您修复它。

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.

不，本身没有锁定机制。但是锁定机制往往只是良好通信的替代品。我相信这就是 Git 开发人员没有添加锁定机制的原因。

回答by Michael Johnson

We've just recently started using Git (used Subversion previously) and I have found a change to workflow that might help with your problem, without the need for locks. It takes advantage of how git is designed and how easy branches are.

我们最近才开始使用 Git（以前使用过 Subversion），我发现工作流程的更改可能有助于解决您的问题，而无需锁定。它利用了 git 的设计方式以及分支的简单性。

Basically, it boils down to pushing to a non-master branch, doing a review of that branch, and then merging into the master branch (or whichever the target branch is).

基本上，它归结为推送到非主分支，对该分支进行，然后合并到主分支（或目标分支中的任何一个）。

The way git is "intended" to be used, each developer publishes their own public repository, which they request others to pull from. I've found that Subversion users have trouble with that. So, instead, we push to branch trees in the central repository, with each user having their own branch tree. For instance, a hierarchy like this might work:

git“打算”使用的方式是，每个开发人员发布自己的公共存储库，他们要求其他人从中提取。我发现 Subversion 用户对此有问题。因此，相反，我们推送到中央存储库中的分支树，每个用户都有自己的分支树。例如，这样的层次结构可能有效：

users/a/feature1
users/a/feature2
users/b/feature3
teams/d/featurey

Feel free to use your own structure. Note I'm also showing topic branches, another common git idiom.

随意使用您自己的结构。注意我还展示了主题分支，这是另一个常见的 git 习惯用法。

Then in a local repo for user a:

然后在用户 a 的本地存储库中：

feature1
feature2

And to get it to central server (origin):

并将其发送到中央服务器（原点）：

git push origin feature1:users/a/feature1

(this can probably be simplified with configuration changes)

（这可能可以通过配置更改来简化）

Anyway, once feature1 is reviewed, whomever is responsible (in our case, it's the developer of the feature, you could have a single user responsible for merges to master), does the following:

无论如何，一旦 feature1 被，无论谁负责（在我们的例子中，它是该功能的开发者，你可以有一个用户负责合并到 master），执行以下操作：

git checkout master
git pull
git merge users/name/feature1
git push

The pull does a fetch (pulling any new master changes andthe feature branch) and the updates master to what the central repository has. If user a did their job and tracked master properly, there should be no problems with the merge.

拉取执行（拉取任何新的主更改和功能分支）并将更新主更新到中央存储库所拥有的内容。如果用户 a 完成了他们的工作并正确跟踪了 master，则合并应该没有问题。

All this means that, even if a user or remote team makes a change to a binary resource, it gets reviewed before it gets incorporated into the master branch. And there is a clear delineation (based on process) as to when something goes into the master branch.

所有这一切意味着，即使用户或远程团队对二进制资源进行了更改，它也会在合并到主分支之前进行。并且有一个明确的描述（基于进程）关于什么时候进入主分支。

You can also programmatically enforce aspects of this using git hooks, but again, I've not worked with these yet, so can't speak on them.

您还可以使用 git hooks 以编程方式强制执行此操作的各个方面，但同样，我还没有使用过这些，因此无法谈论它们。

回答by Khoth

It's worth examining your current workflow to see if locking images is really necessary. It's relatively unusual for two people to independently edit an image, and a bit of communication can go a long way.

值得检查您当前的工作流程，看看是否真的有必要锁定图像。两个人独立编辑图像是比较不寻常的，稍微交流一下就可以走很长的路。

回答by J?rg W Mittag

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

当我使用 Subversion 时，我虔诚地为svn:needs-lock所有二进制文件甚至难以编辑的文本文件设置了该属性。我实际上从未经历过任何冲突。

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.

现在，在 Git 中，我不担心这些事情。请记住：Subversion 中的锁实际上并不是强制锁，它们只是通信工具。你猜怎么着：我不需要 Subversion 来交流，我可以用电子邮件、电话和 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.

我做的另一件事是用纯文本格式替换许多二进制格式。我使用 reStructuredText 或 LaΤ _ΕΧ 代替 Word、CSV 代替 Excel、ASCII-Art 代替 Visio、YAML 代替数据库、SVG 代替 OO Draw、abc 代替 MIDI，等等。

回答by Mario

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

我已经在 git 讨论组上讨论过这个问题，并且得出的结论是，目前还没有一致的 git 集中文件锁定方法。

回答by Dan

This is not a solution but rather a comment on why locking mechanisms are needed. There are some tools used in some fields which use binary only formats which are flat out mission critical and the "use better/different tools" is just not an option. There are no viable alternate tools. The ones I'm familiar with really wouldn't be candidates for merging even if you stored the same information in an ascii format. One objection I've heard is that you want to be able to work offline. The particular tool I'm thinking of really doesn't work offline anyway because of needing to pull licenses so if I have data on a laptop it isn't like I can run the tool while on a train anyway. That said, what git does provide if I have a slow connection, I can get licenses and also pull down changes but have the fast local copy for looking at different versions. That is a nice thing that the DVCS gives you even in this case.

这不是解决方案，而是对为什么需要锁定机制的评论。在某些领域中使用了一些工具，这些工具仅使用二进制格式，这些格式完全是关键任务，并且“使用更好/不同的工具”不是一种选择。没有可行的替代工具。即使您以 ascii 格式存储相同的信息，我熟悉的那些也不会成为合并的候选者。我听到的一个反对意见是，您希望能够离线工作。我正在考虑的特定工具无论如何都无法脱机工作，因为需要获取许可证，因此如果我在笔记本电脑上有数据，那么无论如何我都无法在火车上运行该工具。也就是说，如果我的连接速度很慢，git 会提供什么，我可以获得许可证并下拉更改，但拥有快速的本地副本以查看不同的版本。即使在这种情况下，这是 DVCS 为您提供的一件好事。

One view point is that git is simply not the tool to use but it is nice for all the text files which are also managed with it and it is annoying to need different version control tools for different files.

一种观点是 git 根本不是要使用的工具，但它对所有用它管理的文本文件都很好，并且需要为不同的文件使用不同的版本控制工具很烦人。

The sort-of-advisory-locking-via-mail approach really stinks. I've seen that and have been tired of an endless stream of emails of "I'm editing it" "I'm done editing" and seen changes lost because of it. The particular case I'm thinking of was one where a collection of smaller ascii files would have been much nicer but that is an aside.

那种通过邮件锁定建议的方法真的很糟糕。我已经看到了这一点，并且厌倦了源源不断的“我正在编辑它”“我已经完成编辑”的电子邮件，并且看到更改因此丢失。我正在考虑的特殊情况是一组较小的 ascii 文件会更好，但这是一个问题。

回答by Antonio Bardazzi

TortoiseGit supports full git workflow for Office documents delegating diff to Office itself. It works also delegating to OpenOffice for OpenDocument formats.

TortoiseGit 支持将 diff 委托给 Office 本身的 Office 文档的完整 git 工作流程。它还可以将 OpenDocument 格式委托给 OpenOffice。