一年半以来，我一直在关注git社区，以期改用SVN。使我退缩的一个特殊问题是无法锁定二进制文件。在过去的一年中，我尚未看到有关此问题的进展。我了解锁定文件违反了分布式源代码管理的基本原理，但是当二进制文件存在潜在冲突时，我看不到Web开发公司如何利用git来跟踪源代码和图像文件更改。

为了实现锁定的效果，必须标识一个"中央"存储库。无论git的分布式性质如何，大多数公司都将为软件项目提供一个"中央"存储库。我们应该能够将文件标记为需要来自指定地址的git仓库的锁定。也许由于git跟踪文件内容而不是文件而使这变得困难吗？

你们中的任何人都具有处理git和二进制文件的经验，这些文件应在修改前锁定？

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

解决方案

我不希望文件锁定能够成为git中的功能。我们主要对哪种二进制文件感兴趣？我们实际上对锁定文件感兴趣，还是只是防止由于无法合并而引起的冲突？

我似乎记得有人在谈论(甚至实施)在git中合并OpenOffice文档的支持。

值得检查我们当前的工作流程，以查看是否确实需要锁定图像。两个人独立编辑图像是相对不寻常的，需要一点沟通才能走很长一段路。

我同意锁定二进制文件对于某些环境是必需的功能。我只是想到了如何实现这一点：

• 有一种将文件标记为"需要锁定"的方法(例如" svn：needs-lock"属性)。
• 签出时，git会将此类文件标记为只读。
• 一个新的命令" git-lock"将联系运行在某处的中央锁定服务器，以请求锁定权限。
• 如果锁服务器授予许可，请将该文件标记为可读写。
• git-add将通知锁定服务器锁定文件的内容哈希。
• 锁定服务器将监视该内容哈希是否显示在主存储库中的提交中。
• 出现哈希后，释放锁。

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

在特定组织内，可以使用脚本包装程序和提交钩子的适当组合来构建这种东西。

当我使用Subversion时，我认真地在所有二进制文件甚至难以编辑的文本文件上设置了svn：needs-lock属性。我从未真正经历过任何冲突。

现在，在Git中，我不必担心这些事情。请记住：Subversion中的锁实际上并不是强制性锁，它们只是通信工具。猜猜是什么：我不需要Subversion进行交流，我可以使用电子邮件，电话和IM进行管理。

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

我们最近才刚开始使用Git(以前使用Subversion)，我发现工作流程发生了变化，可以解决问题，而无需锁定。它利用了git的设计方式以及分支的简易性。

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

git是"预期"使用的方式，每个开发人员都会发布自己的公共存储库，并要求其他人从中获取。我发现Subversion用户对此有麻烦。因此，我们改为在中央存储库中推送分支树，每个用户都有自己的分支树。例如，这样的层次结构可能会起作用：

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

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

然后在本地回购中为用户a：

feature1
feature2

并将其发送到中央服务器(来源)：

git push origin feature1:users/a/feature1

(这可能可以通过更改配置来简化)

无论如何，一旦对feature1进行了审核(由谁负责)(在我们的情况下，是功能的开发者，我们可能只有一个用户负责合并到母版)，然后执行以下操作：

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

提取将进行提取(将任何新的主更改和功能分支拉出)，并将更新主更新为中央存储库所具有的内容。如果用户a做好了工作并正确地跟踪了母版，则合并应该没有问题。

所有这一切意味着，即使用户或者远程团队对二进制资源进行了更改，也要先对其进行审核，然后再将其合并到master分支中。并且有明确的描述(基于过程)是什么时候进入master分支的。

我们也可以使用git钩子以编程方式强制执行此方面，但同样，我尚未使用它们，因此无法对其进行说明。

我已经在git讨论组中讨论了这个问题，并得出结论，目前，尚无关于git的集中式文件锁定方法的共识。

为了响应Mario对二进制文件中多个位置发生的更改的额外关注。因此，场景就是Alice和Bob都同时对同一二进制资源进行更改。他们每个人都有自己的本地存储库，这些存储库是从一个中央远程站点克隆的。

这确实是一个潜在的问题。因此，爱丽丝首先完成并推送到中央的" alice / update"分支。通常，发生这种情况时，Alice会宣布应对其进行审查。鲍勃(Bob)看到并对其进行了审查。他可以(1)自己将这些更改合并到他的版本中(从" alice / update"分支并对其进行更改)，或者(2)将自己的更改发布到" bob / update"。他再次宣布。

现在，如果Alice改为使用" master"，则Bob在拉" master"并尝试合并到其本地分支机构时遇到了一个难题。他与爱丽丝的冲突。但是同样，相同的过程也可以适用，只是在不同的分支上。即使Bob忽略了所有警告并提交了有关Alice的警告，也总是有可能撤出Alice的提交以修复问题。这仅仅是一个沟通问题。

由于(AFAIK)Subversion锁只是建议性的，因此电子邮件或者即时消息可以达到相同的目的。但是，即使我们不这样做，Git也会让我们对其进行修复。

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

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

我不同意"锁只是一种通信方法"。与电话或者电子邮件之类的推送通知相比，它们是一种更为有效的方法。 Subversion锁是自我记录的(拥有锁)。另一方面，如果我们必须通过其他传统的推送通知渠道(例如电子邮件)进行通信，则将通知发送给谁？除非我们有整个开发团队的完整列​​表，否则我们不会事先知道谁可能要编辑文件，尤其是在开源项目中。因此，那些传统的交流方法几乎没有效果。

违反DVCS原理的中央锁服务器是不可合并文件的唯一可行方法。只要DVCS没有中央锁功能，我认为它将保持我使用Subversion的公司的地位。

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

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

cad文件呢？如果文件没有被锁定(也保持只读)，大多数cad程序将以任意更改的方式打开它们，任何vc都将其视为新文件。因此，在我看来，锁定是传达我们要更改某些particalur文件的理想方式。同样，它首先会阻止某些软件获得写访问权限。这样就可以更新本地文件，而无需完全关闭软件或者至少完全关闭所有文件。

我不建议在我的公司使用git来解决相同的问题。我们使用EA进行所有设计，使用Microsoft Word进行文档编制，我们事先不知道谁可以编辑特定文件，因此独占锁定是我们唯一的选择。

git在非团队环境中可以很好地工作，在每个团队中，每个开发人员都只负责一段代码或者文件，因为在这种情况下，不需要有关锁的通信。

如果组织需要团队环境(通常是为了剥夺开发人员的工作安全性)，请使用svn，而不适合git。 Svn同时提供源代码控制和开发人员之间有关锁的通信。

只需将一个文本文件和我们要锁定的文件放在cc中，然后让更新挂钩拒绝它即可。