Question

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

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

您是否有经验处理应在修改前锁定的git和二进制文件？

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

Answer 1

Subversion有锁，它们不仅仅是建议性的。可以使用svn:needs-lock属性强制执行它们（但如果需要，也可以故意破坏）。这是管理不可合并文件的正确解决方案。我在Subversion中为商店工作的公司，并使用svn:needs-lock来处理所有不可合并的文件。

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

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

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

Here's an interesting read on the topic.

Answer 2

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

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

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

在特定组织中，可以使用脚本包装器和提交挂钩的适当组合来构建此类事物。

Answer 3

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

这确实是一个潜在的问题。所以Alice先完成并推送到中心alice/update分支。通常情况下，如果发生这种情况，Alice会发布一条通知应该进行审核。鲍勃看到并审查它。他可以（1）将这些变化自己纳入他的版本（从alice/update分支并对其进行更改）或（2）将他自己的更改发布到bob/update。他再次发布公告。

现在，如果Alice推送到master，那么当他拉master并尝试合并到他的本地分支时，Bob会陷入两难境地。他与爱丽丝的冲突。但同样，相同的程序可以适用于不同的分支。即使Bob忽略了Alice的所有警告和提交，也总是可以撤出Alice的修复提议。这只是一个沟通问题。

由于（AFAIK）Subversion锁只是建议性的，因此电子邮件或即时消息可以起到同样的作用。但即使你不这样做，Git也会让你解决它。

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

Answer 4

我们刚刚开始使用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

pull执行获取（将任何新主服务器更改和功能分支）和更新主服务器到中央存储库具有的功能。如果用户a完成了他们的工作并且正确地跟踪了主人，那么合并应该没有问题。

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

你也可以使用git hooks以编程方式强制执行这方面的内容，但同样，我还没有使用过这些，所以不能谈论它们。

Answer 5

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

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

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

Answer 6

当我使用Subversion时，我虔诚地在所有二进制文件上设置svn:needs-lock属性，甚至是难以编辑的文本文件。我永远实际上没有遇到任何冲突。

现在，在Git中，我并不担心这些事情。记住：Subversion中的锁实际上不是强制锁，它们只是通信工具。猜猜看：我不需要Subversion进行沟通，我可以通过电子邮件，电话和即时通讯来管理。

我做的另一件事是用纯文本格式替换许多二进制格式。我使用reStructuredText或LaT _Ε X而不是Word，CSV而不是Excel，ASCII-Art而不是Visio，YAML代替数据库，SVG代替OO Draw，abc代替MIDI，依此类推。

Answer 7

值得检查当前的工作流程，看看是否真的需要锁定图像。对于两个人来说，独立编辑图像是相对不寻常的，而且一些沟通可以有很长的路要走。

Answer 8

我已经在git讨论组上讨论了这个问题，并得出结论，此时有一个没有同意git集中文件锁定的方法。

Answer 9

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

Answer 10

cad文件怎么样？如果文件没有锁定，也要保持只读，大多数cad程序只会打开它们一个任意位的变化，被任何vcs看作是一个新文件。因此，在我看来，锁定是一种理想的方式，用于通信您打算更改某些particalur文件。同样，它可以防止某些软件首先获得写访问权限。这允许更新本地文件，而无需完全关闭软件或至少关闭所有文件。

Answer 11

只需将cc文本文件与要锁定的文件放在cc中，然后让更新挂钩拒绝它。

Answer 12

重组项目可能有助于避免锁定，但是：

团队也按其他优先事项（地点，客户......）进行组织。
其他目标也选择了工具（兼容性，价格，大多数员工的易用性）
有些工具（因此存在二进制文件）是无法避免的，因为根本没有可以完成同样工作的替代工具，以同样的价格为公司的需求提供相同的工作。

要求，整个公司可能会重新组织他们的工作流程并替换所有生成二进制文件的工具，只能使用git，因为缺少锁定，听起来非常低效。

锁不适合git哲学（从未用于二进制文件），但存在不可忽视的情况，其中锁是解决此类问题的最有效方法。

Answer 13

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

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

通过邮件的咨询锁定方式确实很糟糕。我已经看到了，并且已经厌倦了无数的电子邮件“我正在编辑它”“我已经完成了编辑”并且因为它而看到了变化。我正在考虑的特殊情况是，一个较小的ascii文件集合会更好，但这是一个旁边。

Answer 14

我不希望文件锁定永远使它成为git中的一个功能。你最感兴趣的是什么样的二进制文件？您是否真的对锁定文件感兴趣，或者只是防止因无法合并而导致的冲突。

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

Answer 15

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

Answer 16

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

如果您的组织需要团队环境（通常是为了剥离开发人员的工作安全性），那么使用svn，git不适合您。 Svn提供了源代码控制和开发人员之间关于锁的通信。

Answer 17

Git没有提供锁定文件的任何命令，但我已经资助了一种使用git hooks实现该功能的方法。需要辅助服务器来存储锁信息。我们可以使用预提交钩子来检查是否有任何已提交的文件被锁定。如果有人锁定文件，程序应该告诉辅助服务器锁柜和锁定文件的信息。

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

17 个答案: