Git (LFS): 什么是锁定支持？我应该启用它吗？
Git (LFS): what is locking support? And should I enable it?
"New" Git 评论：
就在今天，我 运行 第一次看到 Git 的以下评论（至少我是第一次看到）：
Mikes-Mac$ git push
Locking support detected on remote "origin". Consider enabling it with:
$ git config 'lfs.https://github.com/<my_repo>.git/info/lfs.locksverify' true
Everything up-to-date
Mikes-Mac$
这是什么Locking support？这是 LFS（大文件存储）的某种 mutex locking 吗？如果是这样，让 git 上的任何东西正常工作不是绝对必要的吗？ （至少，如何才能建立日志历史记录的 "ordering"？更糟糕的情况是，我不能让二进制文件被同时写入损坏吗？）
我的操作
我最近没有对这个存储库做任何不同的事情，与我用 LFS 建立的任何其他存储库相比，我对这个存储库也没有做任何不同的事情。
因此，我假设这是向 "the world" 提供的新评论，让我们了解新功能。
没有明显的文档
但是，Google 搜索和 快速 搜索他们的文档都没有让我找到任何解释这一点的方法。所以，我想知道：
- 这是什么锁定？
- 它是互斥体吗？如果是这样，没有它我的回购协议怎么能运行？
- 这仅限于 LFS 吗？它与普通 git 文件锁定有何不同？
- 为 LFS 添加锁定支持的优点和缺点是什么？
Git LFS 的锁定支持记录在此处 https://github.com/git-lfs/git-lfs/wiki/File-Locking。
Git LFS v2.0.0 includes an early release of File Locking. File Locking lets developers lock files they are updating to prevent other users from updating them at the same time. Concurrent edits in Git repositories will lead to merge conflicts, which are very difficult to resolve in large binary files.
Once file patterns in .gitattributes are lockable, Git LFS will make them readonly on the local file system automatically. This prevents users from accidentally editing a file without locking it first.
Git LFS will verify that you're not modifying a file locked by another user when pushing. Since File Locking is an early release, and few LFS servers implement the API, Git LFS won't halt your push if it cannot verify locked files. You'll see a message like this:
$ git lfs push origin master --all
Remote "origin" does not support the LFS locking API. Consider disabling it with:
$ git config 'lfs.http://git-server.com/user/test.locksverify' false
Git LFS: (0 of 0 files, 7 skipped) 0 B / 0 B, 879.11 KB skipped
$ git lfs push origin master --all
Locking support detected on remote "origin". Consider enabling it with:
$ git config 'lfs.http://git-server.com/user/repo.locksverify' true
Git LFS: (0 of 0 files, 7 skipped) 0 B / 0 B, 879.11 KB skipped
所以从某种意义上说，您可以将其视为咨询互斥体，因为：
- 如果不“锁定”文件，则无法编辑
- 一旦您使用
git lfs lock“锁定”文件，您就可以编辑它，存储库服务器会识别出您正在编辑它
- 服务器不会接受其他人更改您锁定的文件的提交。
添加主要是为了帮助团队管理大文件，防止合并冲突。
接受的答案未能回答问题的次要方面，具体而言：
If so, isn't it absolutely essential to get anything on git to work? (Minimally, how else could the "ordering" of the log history be established? Worse case, couldn't I have a binary file corrupted by simultaneous writes?)
所以我只讲那部分。
git 中没有同时写入，历史的排序是答案的一部分！
当您将提交推送到远程 git 存储库时，它会验证您正在推送的提交是存储库已作为该分支的头部的提交的后代。
如果不是，提交将被拒绝。
如果是，那么 git 将发送一组 blob（文件数据）、树 object 和提交。
然后更新分支头以指向您的新提交。
除非 head 改变了，否则它会再次拒绝你的新提交。
如果被拒绝，您必须从远程存储库中拉取较新的更改，并将它们与您的更改合并，或者在新的更改之上重新设置您的更改（例如 git pull -r） .
无论哪种方式，您都会创建一个新的本地提交，它是存储库所具有内容的后代。
然后您可以将此新提交推送到存储库。这个新提交可能会被拒绝，迫使您重复该过程。
文件永远不会被覆盖。文件“mybigfile.mpg”到 git 只是一个具有基于文件内容的 SHA-256 哈希的唯一 ID 的 blob。如果您更改文件，那将是一个具有新 ID 的新 blob。
文件名，这只是树中的一个条目object。这些也有基于其内容哈希的 ID。
如果您重命名文件（或添加、删除等），那将是一棵新树 object，它有自己的 ID。
因为这些是历史的一部分（提交包括正在提交的顶级树的 ID，以及其 parents 的 ID），这些 objects（blob、树、提交、签名标签）只会被添加到存储库中，并且永远不会被修改。
Git历史总是有序的，因为它是一个链表，链接指向parents。初始提交为零次提交，合并提交为两次或更多次，否则为一次。
并且它们不需要任何显式锁定，因为 git 在进行更改之前检查冲突。
只有包含分支上头提交 ID 的文件需要锁定，然后在检查更改和更新它之间只锁定一小段时间。
git-lfs 中的锁解决了一个非常不同的问题。二进制资产通常无法合并，并且经常需要大量的更改工作。
大型资产尤其如此。
如果两个开发人员开始对同一个文件进行更改，则必须放弃一组更改，然后以另一组更改为基础重新创建。
git-lfs 锁定可以防止这种意外发生。如果您遇到锁，您要么等到稍后再进行更改，要么去与拥有该锁的人交谈。
他们可以进行请求的更改，或者他们可以释放锁定并允许您在他们目前所做的更改之上进行更改。完成后，您可以推送您的更改并释放锁定，让他们继续您的更改。
因此，它允许对要序列化的特定文件进行更改（整个开发过程，而不是 file-writing），而不是用于文本源文件的 parallel-then-merge 范例。
"New" Git 评论：
就在今天，我 运行 第一次看到 Git 的以下评论（至少我是第一次看到）：
Mikes-Mac$ git push
Locking support detected on remote "origin". Consider enabling it with:
$ git config 'lfs.https://github.com/<my_repo>.git/info/lfs.locksverify' true
Everything up-to-date
Mikes-Mac$
这是什么Locking support？这是 LFS（大文件存储）的某种 mutex locking 吗？如果是这样，让 git 上的任何东西正常工作不是绝对必要的吗？ （至少，如何才能建立日志历史记录的 "ordering"？更糟糕的情况是，我不能让二进制文件被同时写入损坏吗？）
我的操作
我最近没有对这个存储库做任何不同的事情，与我用 LFS 建立的任何其他存储库相比，我对这个存储库也没有做任何不同的事情。
因此，我假设这是向 "the world" 提供的新评论，让我们了解新功能。
没有明显的文档
但是，Google 搜索和 快速 搜索他们的文档都没有让我找到任何解释这一点的方法。所以，我想知道：
- 这是什么锁定？
- 它是互斥体吗？如果是这样，没有它我的回购协议怎么能运行？
- 这仅限于 LFS 吗？它与普通 git 文件锁定有何不同？
- 为 LFS 添加锁定支持的优点和缺点是什么？
Git LFS 的锁定支持记录在此处 https://github.com/git-lfs/git-lfs/wiki/File-Locking。
Git LFS v2.0.0 includes an early release of File Locking. File Locking lets developers lock files they are updating to prevent other users from updating them at the same time. Concurrent edits in Git repositories will lead to merge conflicts, which are very difficult to resolve in large binary files.
Once file patterns in
.gitattributesare lockable, Git LFS will make them readonly on the local file system automatically. This prevents users from accidentally editing a file without locking it first.
Git LFS will verify that you're not modifying a file locked by another user when pushing. Since File Locking is an early release, and few LFS servers implement the API, Git LFS won't halt your push if it cannot verify locked files. You'll see a message like this:
$ git lfs push origin master --all Remote "origin" does not support the LFS locking API. Consider disabling it with: $ git config 'lfs.http://git-server.com/user/test.locksverify' false Git LFS: (0 of 0 files, 7 skipped) 0 B / 0 B, 879.11 KB skipped$ git lfs push origin master --all Locking support detected on remote "origin". Consider enabling it with: $ git config 'lfs.http://git-server.com/user/repo.locksverify' true Git LFS: (0 of 0 files, 7 skipped) 0 B / 0 B, 879.11 KB skipped
所以从某种意义上说，您可以将其视为咨询互斥体，因为：
- 如果不“锁定”文件，则无法编辑
- 一旦您使用
git lfs lock“锁定”文件，您就可以编辑它，存储库服务器会识别出您正在编辑它 - 服务器不会接受其他人更改您锁定的文件的提交。
添加主要是为了帮助团队管理大文件，防止合并冲突。
接受的答案未能回答问题的次要方面，具体而言：
If so, isn't it absolutely essential to get anything on git to work? (Minimally, how else could the "ordering" of the log history be established? Worse case, couldn't I have a binary file corrupted by simultaneous writes?)
所以我只讲那部分。
git 中没有同时写入，历史的排序是答案的一部分！
当您将提交推送到远程 git 存储库时，它会验证您正在推送的提交是存储库已作为该分支的头部的提交的后代。
如果不是，提交将被拒绝。
如果是，那么 git 将发送一组 blob（文件数据）、树 object 和提交。
然后更新分支头以指向您的新提交。
除非 head 改变了，否则它会再次拒绝你的新提交。
如果被拒绝，您必须从远程存储库中拉取较新的更改，并将它们与您的更改合并，或者在新的更改之上重新设置您的更改（例如 git pull -r） .
无论哪种方式，您都会创建一个新的本地提交，它是存储库所具有内容的后代。
然后您可以将此新提交推送到存储库。这个新提交可能会被拒绝，迫使您重复该过程。
文件永远不会被覆盖。文件“mybigfile.mpg”到 git 只是一个具有基于文件内容的 SHA-256 哈希的唯一 ID 的 blob。如果您更改文件，那将是一个具有新 ID 的新 blob。
文件名，这只是树中的一个条目object。这些也有基于其内容哈希的 ID。
如果您重命名文件（或添加、删除等），那将是一棵新树 object，它有自己的 ID。
因为这些是历史的一部分（提交包括正在提交的顶级树的 ID，以及其 parents 的 ID），这些 objects（blob、树、提交、签名标签）只会被添加到存储库中，并且永远不会被修改。
Git历史总是有序的，因为它是一个链表，链接指向parents。初始提交为零次提交，合并提交为两次或更多次，否则为一次。
并且它们不需要任何显式锁定，因为 git 在进行更改之前检查冲突。
只有包含分支上头提交 ID 的文件需要锁定，然后在检查更改和更新它之间只锁定一小段时间。
git-lfs 中的锁解决了一个非常不同的问题。二进制资产通常无法合并，并且经常需要大量的更改工作。
大型资产尤其如此。
如果两个开发人员开始对同一个文件进行更改，则必须放弃一组更改，然后以另一组更改为基础重新创建。
git-lfs 锁定可以防止这种意外发生。如果您遇到锁，您要么等到稍后再进行更改，要么去与拥有该锁的人交谈。
他们可以进行请求的更改，或者他们可以释放锁定并允许您在他们目前所做的更改之上进行更改。完成后，您可以推送您的更改并释放锁定，让他们继续您的更改。
因此，它允许对要序列化的特定文件进行更改（整个开发过程，而不是 file-writing），而不是用于文本源文件的 parallel-then-merge 范例。