使用git版本控制系统locking二进制文件
一年半来，我一直在关注git社区，希望能够摆脱SVN。 一个特定的问题阻碍我是无法locking二进制文件。 在过去的一年中，我还没有看到这个问题的发展。 我知道locking文件违背了分布式源代码控制的基本原则，但是我不明白在二进制文件冲突的潜在可能性时，Web开发公司如何利用git来跟踪源代码和映像文件的变化。
为了实现locking的效果，必须确定一个“中央”存储库。 不pipegit的分布式性质如何，大多数公司将拥有一个软件项目的“中心”存储库。 我们应该能够将文件标记为需要从指定地址的pipe理git存储库进行locking。 也许这是困难的，因为git跟踪文件内容不是文件？
你们有没有经验处理git和二进制文件，应修改之前locking？
注意：它看起来像Source Gear的新开源分布式版本控制项目Veracity，已经locking为其目标之一。
Git LFS 2.0增加了对文件locking的支持。
使用Git LFS 2.0.0，您现在可以locking您正在使用的文件，在您再次解锁文件之前，阻止其他人推送到Git LFS服务器。
这将防止合并冲突以及在文件系统级别的不可兼容文件上丢失工作。 虽然看起来与Git的分布式和并行性质相矛盾，但是文件locking是许多软件开发工作stream程的重要组成部分，特别是对于使用二进制资源的大型团队。
Subversion有锁，它们不只是build议。 可以使用svn:needs-lock属性强制执行它们（但如果需要也可以故意破坏它们）。 这是pipe理不可合并文件的正确解决scheme。 我工作的公司只是在Subversion里面存储所有的东西，并且使用svn:needs-lock来处理所有不可合并的文件。
我不同意“锁只是一种沟通方式”。 与推送通知（例如电话或电子邮件）相比，这是一种更为有效的方法。 Subversion锁是自我logging（谁拥有锁）。 另一方面，如果您必须通过其他传统的推送通知渠道（例如电子邮件）进行通信，那么您将通知发送给谁？ 除非您有完整的开发团队的完整列表，否则您事先并不知道谁可能要编辑该文件，特别是在开源项目中。 所以这些传统的沟通方式几乎没有效果。
中央锁服务器虽然违背DVCS的原则，但对于不可兼容的文件来说，这是唯一可行的方法。 只要DVCS不具备中央lockingfunction，我认为这将使我使用Subversion的公司保持工作。
更好的解决scheme是为所有的二进制文件格式创build一个合并工具，但这是一个永远不会“完成”的长期和持续的目标。
这里有一个有趣的阅读主题。
我同意locking二进制文件是一些环境的必要function。 我只是想了解如何实现这个，但是：
- 有一种标记文件为“需要locking”（如“svn：needs-lock”属性）的方法。
- 在结帐时，git会将这样的文件标记为只读。
- 一个新的
git-lock命令会联系一个运行在某个地方的中央锁服务器来请求locking权限。 - 如果锁服务器授予权限，则将该文件标记为可读写。
-
git-add会通知locking服务器locking文件的内容哈希。 - 锁服务器会监视内容哈希出现在主存储库的提交中。
- 当哈希出现时，释放locking。
这是一个非常糟糕的想法，到处都有潜在的漏洞。 这也违背git的精神，但在某些情况下它肯定会有用。
在一个特定的组织中，这种事情可能可以使用脚本包装器和提交钩子的适当组合来构build。
为了回应马里奥对二进制文件多处发生变化的额外关注。 所以情况是Alice和Bob都在同一时间对相同的二进制资源进行更改。 他们都有自己的本地回购，从一个中央偏远地区克隆。
这确实是一个潜在的问题。 所以爱丽丝首先完成，并推到中央alice/update分支。 通常情况下，Alice会发布一个消息，要求对其进行审查。 鲍勃看到并审查它。 他可以（1）将这些改变本身纳入他的版本（从alice/update分支并对其进行修改），或者（2）发布他自己的更改bob/update 。 他再次发表声明。
现在，如果爱丽丝把master推到了master身边，鲍勃有一个两难的局面，他拉着master ，试图融入当地的分支。 他与爱丽丝的冲突。 但是，同样的过程也适用于不同的分支。 即使鲍勃忽略了对爱丽丝的所有警告和承诺，也总是有可能撤销爱丽丝的承诺来解决问题。 这只是一个沟通问题。
由于（AFAIK）Subversion锁只是build议性的，电子邮件或即时消息可以达到同样的目的。 但即使你不这样做，Git让你修复它。
不，没有locking机制本身。 但locking机制往往只是一个良好的沟通的替代品。 我相信这就是为什么Git开发者没有添加locking机制。
我们刚刚开始使用Git（之前使用过Subversion），我发现工作stream的变化可能会帮助您解决问题，而不需要locking。 它利用了git的devise和分支是如何简单的。
基本上，归结为推到非主分支，对该分支进行审查，然后合并到主分支（或者目标分支）中。
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
（这可以通过configuration更改来简化）
无论如何，一旦feature1被审查，谁负责（在我们的例子中，这是该function的开发人员，你可以让一个用户负责合并掌握），请执行以下操作：
git checkout master git pull git merge users/name/feature1 git push
拉取（抓取任何新的主变更和特征分支），更新掌握中央资料库的内容。 如果用户a完成了他们的工作并正确地跟踪了主人，那么合并应该没有问题。
所有这一切意味着，即使用户或远程团队对二进制资源进行了更改，也会在将其纳入主分支之前进行审查。 关于什么时候进入主分支，有一个清晰的划分（基于过程）。
你也可以使用git钩子以编程的方式强制执行这个方面，但是我还没有用过这些方法，所以不能说出来。
当我使用Subversion的时候，我对所有的二进制文件，甚至是难以编辑的文本文件都进行了宗教设置，使用了svn:needs-lock属性。 我从来没有遇到任何冲突。
现在，在Git中，我不担心这样的事情。 记住：Subversion中的锁实际上并不是强制性的锁，它们只是通信工具。 并猜测：我不需要Subversion进行通信，我可以使用电子邮件，电话和即时通讯进行pipe理。
我做的另一件事，是用纯文本格式replace很多二进制格式。 我使用reStructuredText或LaTΕΧ而不是Word，CSV代替Excel，ASCII-Art代替Visio，YAML代替数据库，SVG代替OO Draw，abc代替MIDI等等。
检查您目前的工作stream程是值得的，看看locking图像是否真的有必要。 两个人独立编辑图像是相当不寻常的，一点沟通可以走得很远。
我已经在git讨论组上讨论过这个问题，并且得出结论，目前还没有一致的git集中式文件locking方法。
TortoiseGit支持完整的git工作stream程，用于将文档委托给Office本身。 它也可以委托OpenOffice for OpenDocument格式。
我不希望文件locking永远把它作为一个function在混帐。 你主要关心什么样的二进制文件？ 你真的有兴趣locking文件，或只是防止由于不能合并它们而导致的冲突。
我似乎记得有人在讨论（甚至实现）在git中合并OpenOffice文档的支持。
那么cad文件呢？ 如果这些文件没有被locking，只能保持为只读模式，那么大多数cad程序只会打开它们的任意位，被任何vcs看作一个新文件。 所以在我看来，locking是一个沟通你打算改变一些分文档的理想手段。 另外，它还可以防止某些软件获得写入权限。 这允许更新本地文件，而不需要closures软件或至less所有的文件完全。
git在非团队环境中工作得非常好，每个开发者只负责一段代码或文件，因为在那种情况下，不需要关于锁的通信。
如果你的组织需要团队环境（通常是剥离开发者的工作安全），那么使用svn，git不适合你。 Svn提供了源代码控制和开发者之间关于锁的通信。
只需要将一个文本文件放在你想locking的文件中，然后让更新钩子拒绝它。
可能是这样的，重组项目可以帮助避免locking，但是：
- 团队也由其他优先事项组织（地点，客户…）
- 工具也被其他目标select（兼容性，价格，大部分员工的易用性）
- 有些工具（因此有二进制文件）是不可避免的，因为没有替代品可以做同样的工作，以相同的价格满足公司的需求。
为了要求，整个公司可能会重新组织他们的工作stream程并replace所有产生二进制文件的工具，但由于没有locking，只能使用git，听起来效率很低。
锁不适合git哲学（从来没有用于二进制），但有一些不可忽视的情况，锁是解决这个问题最有效的方法。
这不是一个解决scheme，而是一个为什么需要locking机制的评论。 在一些使用二进制格式的领域中有一些工具被使用，这些格式是关键任务，“使用更好的/不同的工具”不是一种select。 没有可行的替代工具。 即使您以ASCII格式存储相同的信息，我所熟悉的那些实际上也不会成为合并的候选对象。 我听到的一个反对意见是，你希望能够脱机工作。 我正在考虑的特定工具实际上无法离线工作，因为需要取得许可证，所以如果我在笔记本电脑上有数据，那么不pipe我在火车上运行该工具。 也就是说，如果我的连接速度很慢，git会提供什么，我可以获取许可证，并且还可以下拉更改，但是具有快速的本地副本以查看不同的版本。 在这种情况下，这是DVCS给你的好东西。
一个观点是，git根本就不是使用的工具，但是对于所有使用它的文本文件来说都不错，而且对于不同的文件需要不同的版本控制工具也很麻烦。
这种顾问式的locking方式真的很糟糕。 我已经看到了，并已经厌倦了“我正在编辑它”的电子邮件“我正在编辑”，并看到因此而失去的改变。 我想到的特殊情况是，一些较小的ascii文件会更好，但是这是一个问题。
我不build议在我的公司使用git来解决同样的问题。 我们使用EA作为我们所有的devise和微软文档，我们并不知道谁可以编辑一个特定的文件，所以排他锁是我们唯一的select。
Git没有提供任何命令来locking文件，但我已经资助一种使用git钩子实现该function的方法。 需要辅助服务器来存储locking信息。 我们可以使用预先提交的钩子来检查是否有任何提交的文件被locking。 如果有人locking一个文件，程序应该告诉辅助服务器锁柜的信息和locking的文件。
