git ! [远程拒绝] master -> master(锁定失败)

Question

我无法推送到我的 git 存储库。 git clone和 git pull工作正常，但 git push不起作用。

我检查了其他答案，如 here尝试了几种方法，例如 git push origin master --force .但错误仍然相同。

这是屏幕截图。



其他详情:

$ git show-ref refs/remotes/origin/master
8a205a0741f85fa309031a45f3613bf95a99148f refs/remotes/origin/master

$ git rev-parse --symbolic-full-name master
refs/heads/master

$ git rev-parse master
35ae39a241cd6bbfe7a9092f72b08279159e0056

$ git show-ref master
35ae39a241cd6bbfe7a9092f72b08279159e0056 refs/heads/master
8a205a0741f85fa309031a45f3613bf95a99148f refs/remotes/origin/master

请帮助我摆脱这个错误。

更新

$ git ls-remote
From https://xxx.git
8a205a0741f85fa309031a45f3613bf95a99148f        HEAD
8a205a0741f85fa309031a45f3613bf95a99148f        refs/heads/master
58feda6564bd52b9cce53da9862343aefd704202        refs/heads/new-0505
f24cd00e2f587689cdb92671769817c271bf0759        refs/heads/telestop
2a1afdf637a9108471eeddc755d49b74ef51e567        refs/meta/gitblit/reflog
8a205a0741f85fa309031a45f3613bf95a99148f        refs/remotes/origin/master

Answer 1

这种失败有多种可能的原因。根据 comment原来这是一个挥之不去的master.lock服务器上的文件。手动删除它就足够了。

因为失败的原因可能不止一个，所以仅仅提供一个具体的答案并没有多大用处。但是，我们可以在这里概述一般过程，以及可能出现的问题。

请记住，分支和标签名称是引用或引用的特定形式。每个人只持有一个哈希 ID。标签名称通常包含标签对象(生成带注释的标签)或提交对象的哈希 ID，并且一旦创建，永远不会更改。然而，分支名称标识提交链中的一个提交，并且该提交被视为属于该分支的最后一个提交。 (可能有后续提交，但它们不包含在该分支中。请注意，由分支名称标识的提交可以包含在其他分支中。)这样做的结果是这些值随着分支的增长而定期更改.因此必须更新 配对。

这些名称-值对可能应该保存在某种事务数据库中，但实际上不是。 Git 当前(截至今天 2.26.2 版本的所有版本，可能还会持续很长一段时间)将所有这些引用存储在两个位置之一或两个位置:一个名为 packed-refs 的平面文件。 ，或存储在文件系统中的单个文件，例如， refs/heads/master .为了查找名称，Git 首先检查单个文件是否存在。如果是这样，该文件将具有正确的值。如果没有，Git 会检查名称是否存在于 packed-refs 中。文件，如果是，则使用那里的值。如果两个搜索都失败，则该名称不存在。

为了确保任何更新都是原子的——当一个 Git 命令正在更新一个名字时，没有其他 Git 命令可以更新它——Git 使用了一个仔细的创建序列 .lock文件。例如，更新 refs/heads/master , Git 先创建 refs/heads/master.lock .1 主机操作系统必须(并且确实)为此提供“创建文件，但如果文件已经存在则失败”操作。

这里可能会出错。例如，假设目录(或文件夹，如果您更喜欢该术语) refs/heads/拒绝对正在处理 git push 的用户 ID 的创建新文件权限过程。在这种情况下，创建 master.lock将因“权限被拒绝”类型的错误而失败。

在您的特定情况下， master.lock文件已经存在。通常，创建、写入、然后删除或重命名此类文件。但是，如果发生电源故障、系统崩溃或 Git 程序的其他突然终止，系统不会处于良好状态。特别是 .lock文件继续存在。

对于电源故障或系统崩溃，可以进去去除挥之不去的 .lock系统启动时的文件。实际上，这在大多数服务器上并不常见，人们可以像您一样手动修复他们的 Git 服务器。 Git 程序通常也不应该被操作系统突然杀死，但有些系统使用“内存不足杀手”(OOM-killers)，这有时会导致此类问题。

1已创建合适的 .lock文件，Git 将继续将新值写入锁定文件，然后使用原子重命名操作更改 master.lock文件转换为名为 master 的文件, 删除任何以前的文件。这既释放锁又存储新值，所有这些都以这样一种方式，以便任何其他需要该值的 Git 命令都能看到新值。

Git 使用相同的技术来创建 index.lock在更新其索引文件时，但由于索引条目从未从一个 Git 传输到另一个 Git，因此此处的任何故障始终纯粹是本地的，而不是在 git push 期间。 .这种技术还有一个特点，就是可以通过简单地删除锁文件来“回滚”一个“事务”，而不是将锁文件重命名为主名称。

记住术语 ACID使用数据库时:原子性、一致性、隔离性、持久性。 .lock文件技术提供原子性，如果操作系统做出正确的保证，一致性和持久性。但是，隔离属性完全缺失:我们无法自行更新一个数据库字段。这就是为什么 Git 为每个引用使用单独的文件(除非，当它不使用时，通过 packed-refs 文件，因此该文件实际上是只读的:只有一个 Git 程序， git pack-refs 会更新它，使用它自己更复杂的锁定)。

在处理超大索引时，缺乏隔离也会很痛苦。为此，Git 可以使用“拆分索引”模式，其中一些条目(最近未更改的条目)位于第二个文件中，只有“主动更改”条目位于主 .git/index 中。文件。

(使用真实数据库可以解决所有这些问题以及其他多个问题，但真实数据库很复杂。)