一年半以来，我一直在关注git社区，希望从SVN转向。使我退缩的一个特殊问题是无法锁定二进制文件。在过去的一年中，我尚未看到有关此问题的进展。我知道锁定文件违反了分布式源代码管理的基本原理，但是当二进制文件存在潜在冲突时，我看不到Web开发公司如何利用git来跟踪源代码和图像文件更改。
为了实现锁定的效果，必须标识“中央”存储库。无论git的分布式性质如何，大多数公司都将为软件项目提供“中央”存储库。我们应该能够将文件标记为需要来自指定地址的git仓库的锁定。也许由于git跟踪文件内容而不是文件而使这变得困难吗？
你们中的任何人都具有处理git和二进制文件的经验，这些文件应在修改前锁定？
注意：看起来Source Gear的新开源分布式版本控制项目Veracity已将锁定作为其目标之一。
Answers:
Git LFS 2.0增加了对文件锁定的支持。
使用Git LFS 2.0.0，您现在可以锁定正在处理的文件，从而防止其他人将文件推送到Git LFS服务器，直到再次解锁文件为止。
这将防止合并冲突以及文件系统级别上不可合并文件上的工作丢失。尽管文件锁定似乎与Git的分布式和并行性相矛盾，但文件锁定是许多软件开发工作流程的重要组成部分，尤其是对于使用二进制资产的大型团队而言。
Subversion有锁，而不仅仅是咨询。可以使用svn:needs-lock属性强制执行这些操作（但也可以在必要时故意将其破坏）。这是管理不可合并文件的正确解决方案。我工作的公司几乎存储了Subversion中的所有内容，并svn:needs-lock用于所有不可合并的文件。
我不同意“锁只是一种通信方法”。与电话或电子邮件之类的推送通知相比，它们是一种更为有效的方法。Subversion锁是自记录的（拥有锁）。另一方面，如果您必须通过其他传统的推送通知渠道（例如电子邮件）进行通信，则将通知发送给谁？除非您有整个开发团队的完整列表，否则您不会事先知道谁可能要编辑文件，尤其是在开源项目中。因此，这些传统的交流方法几乎没有效果。
违反DVCS原理的中央锁服务器是不可合并文件的唯一可行方法。只要DVCS没有中央锁功能，我认为它将保持我使用Subversion的公司的地位。
更好的解决方案是为所有二进制文件格式制作一个合并工具，但这是一个长期而持续的目标，永远不会“完成”。
我同意锁定二进制文件对于某些环境是必需的功能。我只是想到了如何实现这一点：
git-lock将联系运行在某处的中央锁定服务器，以请求锁定权限。git-add 会通知锁定服务器锁定文件的内容哈希。这是一个半生半熟的想法，到处都有潜在的漏洞。它也违背了git的精神，但是在某些情况下肯定是有用的。
在特定组织内，可以使用脚本包装程序和提交钩子的适当组合来构建这种东西。
为了回应马里奥（Mario）对二进制文件中多个地方发生的更改的额外关注。因此，场景就是Alice和Bob都同时对同一二进制资源进行更改。他们每个人都有自己的本地存储库，这些存储库是从一个中央远程站点克隆的。
这确实是一个潜在的问题。因此，爱丽丝首先完成并推进到中心alice/update分支。通常，发生这种情况时，Alice会宣布应对其进行审查。鲍勃看到了，并对其进行了审查。他可以（1）自己将这些更改合并到他的版本中（从该版本分支alice/update并对其进行更改），或者（2）将自己的更改发布到bob/update。他再次宣布。
现在，如果爱丽丝（Alice）改master而推，鲍勃（Bob）在master尝试合并到其本地分支机构时将陷入困境。他与爱丽丝的冲突。但是同样，相同的过程可以应用于不同的分支。即使Bob忽略了所有警告并提交了有关Alice的警告，也总是有可能撤出Alice的提交以修复问题。这仅仅是一个沟通问题。
由于（AFAIK）Subversion锁只是建议性的，因此电子邮件或即时消息可以达到相同的目的。但是，即使您不这样做，Git也会让您对其进行修复。
不，本身没有锁定机制。但是锁定机制往往只是良好通信的替代品。我相信这就是Git开发人员未添加锁定机制的原因。
我们最近才刚开始使用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 hooks以编程方式强制执行此方面的操作，但是同样，我还没有使用过它们，因此无法对其进行说明。
当我使用Subversion时，我svn:needs-lock认真地设置了所有二进制文件甚至是难以编辑的文本文件的属性。我从未真正经历过任何冲突。
现在，在Git中，我不必担心这些事情。请记住：Subversion中的锁实际上并不是强制性锁，它们只是通信工具。猜猜是什么：我不需要Subversion进行通信，我可以使用电子邮件，电话和IM进行管理。
我要做的另一件事是用纯文本格式替换了许多二进制格式。我用新结构化或LaΤ Ε Χ而不是字，CSV，而不是Excel中，ASCII艺术，而不是Visio中，YAML而不是数据库，SVG的，而不是面向对象的绘制，而不是ABC的MIDI等。
这不是解决方案，而是关于为什么需要锁定机制的评论。在某些领域中使用了一些工具，这些工具仅使用二进制格式，这些格式对任务至关重要，因此“使用更好/不同的工具”不是一个选择。没有可行的替代工具。即使您以ascii格式存储了相同的信息，我熟悉的信息实际上也不适合合并。我听到的一个反对意见是您希望能够脱机工作。我正在考虑使用的特定工具确实确实不能脱机工作，因为需要拉取许可证，因此，如果我在笔记本电脑上拥有数据，那无论如何我都无法在火车上运行该工具。也就是说，如果我的连接速度较慢，git会提供什么，我可以获得许可证，还可以进行更改，但是拥有快速的本地副本，可以查看不同的版本。即使在这种情况下，DVCS也会给您带来好处。
一种观点认为，git根本不是要使用的工具，但是它对于所有使用该工具管理的文本文件也很好，并且烦人的是需要针对不同文件的不同版本控制工具。
那种通过邮件锁定建议的方式真的很臭。我已经看到了这一点，并且厌倦了无休止的“我正在编辑”，“我已经完成编辑”的电子邮件流，并看到更改因此而丢失。我正在考虑的一种特殊情况是，一个较小的ascii文件集合会好得多，但这是一个问题。
cad文件呢？如果文件没有被锁定（也保持只读），大多数cad程序将以任意更改的方式打开它们，任何vc都将其视为新文件。因此，在我看来，锁定是传达您打算更改某些particalur文件的理想方法。同样，它首先会阻止某些软件获得写访问权限。这样就可以更新本地文件，而无需完全关闭软件或至少完全关闭所有文件。
TortoiseGit支持将diff委托给Office本身的Office文档的完整git工作流。它也可以委派给OpenOffice for OpenDocument格式。
我不建议在我的公司使用git来解决相同的问题。我们使用EA进行所有设计，使用Microsoft Word进行文档编制，我们不预先知道谁可以编辑特定文件，因此独占锁定是我们唯一的选择。
git将在非团队环境中很好地工作，在该环境中，每个开发人员仅负责一段代码或文件，因为在这种情况下，不需要有关锁的通信。
如果您的组织需要团队环境（通常是为了剥夺开发人员的工作安全性），请使用svn，而不适合git。Svn同时提供源代码控制和开发人员之间有关锁的通信。