一年半以来，我一直在关注 git 社区，希望能够摆脱 SVN。阻碍我的一个特殊问题是无法锁定二进制文件。在过去的一年里，我还没有看到这个问题的进展。我知道锁定文件违背了分布式源代码控制的基本原则，但我不知道当存在二进制文件冲突的可能性时，Web 开发公司如何利用 git 来跟踪源代码和图像文件的更改。
为了达到锁定的效果，必须确定一个“中央”存储库。不管 git 的分布式特性如何，大多数公司都会有一个软件项目的“中央”存储库。我们应该能够将文件标记为需要从指定地址的管理 git 存储库中锁定。也许这很困难，因为 git 跟踪文件内容而不是文件？
你们有没有处理过修改前应该锁定的 git 和二进制文件的经验？
注意：Source Gear 的新开源分布式版本控制项目 Veracity 似乎将锁定作为其目标之一。
Subversion 有锁，它们不仅仅是建议性的。它们可以使用svn:needs-lock属性强制执行（但也可以在必要时故意破坏）。这是管理不可合并文件的正确解决方案。我工作的公司几乎存储了 Subversion 中的所有内容，并svn:needs-lock用于所有不可合并的文件。
我不同意“锁只是一种交流方式”。它们是比电话或电子邮件等推送通知更有效的方法。Subversion 锁是自记录的（谁拥有锁）。另一方面，如果您必须通过其他传统的推送通知渠道（例如电子邮件）进行通信，您会将通知发送给谁？除非您拥有整个开发团队的完整列表，否则您事先不知道谁可能想要编辑该文件，尤其是在开源项目中。所以那些传统的沟通方法几乎没有那么有效。
中央锁服务器虽然违反了 DVCS 的原则，但对于不可合并的文件来说是唯一可行的方法。只要 DVCS 没有中央锁定功能，我认为它会让我工作的公司继续使用 Subversion。
更好的解决方案是为所有二进制文件格式制作一个合并工具，但这是一个永远不会“完成”的长期和持续目标。
我同意锁定二进制文件是某些环境的必要功能。不过，我只是想到了如何实现这一点：
git-lock将联系在某处运行的中央锁服务器以请求锁定权限。git-add将通知锁定服务器锁定文件的内容哈希。这是一个非常不成熟的想法，到处都有潜在的漏洞。它也违背了 git 的精神，但它在某些情况下肯定是有用的。
在一个特定的组织中，这种事情也许可以使用脚本包装器和提交钩子的适当组合来构建。
为了回应马里奥对二进制文件多个位置发生变化的额外担忧。所以场景是 Alice 和 Bob 同时对同一个二进制资源进行更改。他们每个人都有自己的本地仓库，从一个中央远程克隆。
这确实是一个潜在的问题。所以 Alice 先完成并推送到中央alice/update分支。通常，当这种情况发生时，Alice 会宣布应该对其进行审查。Bob 看到并对其进行了审查。他可以 (1) 自己将这些更改合并到他的版本中（从该版本分支alice/update并对其进行更改）或 (2) 将他自己的更改发布到bob/update. 他再次宣布。
现在，如果 Alice 改为masterpush ，Bob 在拉master并试图合并到他的本地分支时会进退两难。他与爱丽丝的冲突。但同样，同样的程序可以适用于不同的分支。即使 Bob 忽略了所有的警告并提交了 Alice 的，也总是有可能撤回 Alice 的提交来修复问题。这变成了一个简单的沟通问题。
由于（AFAIK）Subversion 锁只是建议性的，因此电子邮件或即时消息可以达到相同的目的。但即使你不这样做，Git 也会让你修复它。
不，本身没有锁定机制。但是锁定机制往往只是良好沟通的替代品。我相信这就是 Git 开发人员没有添加锁定机制的原因。
Git LFS 2.0增加了对文件锁定的支持。
使用 Git LFS 2.0.0，您现在可以锁定您正在积极处理的文件，防止其他人推送到 Git LFS 服务器，直到您再次解锁文件。
这将防止合并冲突以及在文件系统级别丢失不可合并文件的工作。虽然这似乎与 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 被审查，谁负责（在我们的例子中，它是功能的开发者，你可以让一个用户负责合并到 master），执行以下操作：
git checkout master
git pull
git merge users/name/feature1
git push
拉取（拉取任何新的主更改和功能分支）并将主更新到中央存储库所拥有的内容。如果用户 a 完成了他们的工作并正确跟踪了 master，则合并应该没有问题。
所有这一切意味着，即使用户或远程团队对二进制资源进行了更改，它也会在合并到主分支之前得到审查。并且有一个清晰的描述（基于流程）关于什么时候进入主分支。
你也可以使用 git hooks 以编程方式强制执行这些方面，但同样，我还没有使用过这些，所以不能谈论它们。
值得检查您当前的工作流程，看看是否真的需要锁定图像。两个人独立编辑图像是相对不寻常的，一点沟通可以走很长的路。
当我使用 Subversion 时，我虔诚svn:needs-lock地为所有二进制文件甚至是难以编辑的文本文件设置了该属性。我实际上从未经历过任何冲突。
现在，在 Git 中，我不担心这些事情。请记住：Subversion 中的锁实际上并不是强制锁，它们只是通信工具。你猜怎么着：我不需要 Subversion 来沟通，我可以很好地处理电子邮件、电话和 IM。
我做的另一件事是用纯文本格式替换许多二进制格式。我使用 reStructuredText 或 LaΤ ΕΧ代替Word，CSV 代替 Excel，ASCII-Art 代替 Visio，YAML 代替数据库，SVG 代替 OO Draw，abc 代替 MIDI，等等。
我已经在 git 讨论组上讨论过这个问题，并且得出的结论是，目前还没有就 git 集中文件锁定的方法达成一致。
我不希望文件锁定成为 git 中的一项功能。您主要对哪种二进制文件感兴趣？您是否真的对锁定文件感兴趣，或者只是防止由于无法合并它们而引起的冲突。
我似乎记得有人谈论（甚至实现）在 git 中合并 OpenOffice 文档的支持。
这不是一个解决方案，而是对为什么需要锁定机制的评论。在某些领域中使用了一些仅使用二进制格式的工具，这些格式对于任务至关重要，并且“使用更好/不同的工具”不是一种选择。没有可行的替代工具。即使您以 ascii 格式存储相同的信息，我熟悉的那些也不会成为合并的候选者。我听到的一个反对意见是您希望能够离线工作。我正在考虑的特定工具无论如何都不能离线工作，因为需要提取许可证，所以如果我在笔记本电脑上有数据，无论如何我都不能在火车上运行该工具。也就是说，如果我的连接速度很慢，git 会提供什么，我可以获得许可证并下拉更改，但拥有快速的本地副本来查看不同的版本。即使在这种情况下，这也是 DVCS 为您提供的一件好事。
一种观点是 git 根本不是要使用的工具，但它对所有使用它管理的文本文件都很好，而且需要为不同的文件使用不同的版本控制工具很烦人。
那种通过邮件锁定咨询的方法真的很臭。我已经看到了这一点，并且已经厌倦了源源不断的“我正在编辑它”“我已经完成编辑”的电子邮件，并且看到了因此而丢失的更改。我正在考虑的特殊情况是一组较小的 ascii 文件会更好，但这是一个问题。
cad文件呢？如果文件未锁定，也保持只读状态，大多数 cad 程序只会打开它们更改任意位，任何 vcs 都将其视为新文件。因此，在我看来，锁定是传达您打算更改某些特定文件的理想方式。同样，它首先会阻止某些软件获得写入权限。这允许更新本地文件，而无需关闭软件或至少完全关闭所有文件。
TortoiseGit 支持 Office 文档的完整 git 工作流，将差异委托给 Office 本身。它还可以将 OpenDocument 格式委托给 OpenOffice。
我不建议在我的公司使用 git 来解决同样的问题。我们所有的设计都使用 EA，文档使用 microsoft word，我们事先不知道谁可以编辑特定文件，因此排他锁定是我们唯一的选择。
git 在每个开发人员单独负责一段代码或文件的非团队环境中工作得很好，因为在这种情况下不需要关于锁的通信。
如果你的组织需要团队环境（通常是为了剥夺开发人员的工作保障），那么使用 svn，git 不适合你。Svn 提供了源代码控制和开发人员之间关于锁的通信。
只需在 cc 中放入一个文本文件，其中包含您要锁定的文件，然后让更新挂钩拒绝它。
重组项目有助于避免锁定可能是真的，但是：
要求整个公司重新组织他们的工作流程并替换他们所有生成二进制文件的工具，只为了能够使用 git，因为没有锁，这听起来效率很低。
锁不符合 git 哲学（从来没有为二进制文件设计过），但在某些不可忽视的情况下，锁是解决此类问题的最有效方法。
Git 没有提供任何锁定文件的命令，但我已经资助了一种使用 git 挂钩来实现该功能的方法。需要一个辅助服务器来存储锁信息。我们可以使用预提交挂钩来检查是否有任何已提交的文件被锁定。如果有人锁定了一个文件，程序应该告诉辅助服务器锁的信息和被锁定的文件。