git 中的分支损坏，致命：您当前的分支似乎已损坏答案

【问题标题】：Broken branch in git, fatal: your current branch appears to be brokengit 中的分支损坏，致命：您当前的分支似乎已损坏
【发布时间】：2016-01-05 21:40:40
【问题描述】：

这是我的情况：

我在一个分支上工作。
将新提交推送到远程。
切换回主分支。

但是在输入git checkout master 命令后我的电脑突然遇到blue screen of death 并且发生了意外的强制关闭。重新启动计算机后，我检查了当前分支的状态，结果我将每个文件都标记为新文件。

现在，我被困在这一点上，在git log 命令之后我收到错误

$ git log
fatal: your current branch appears to be broken

如何解决这个问题并恢复我的分支？

我正在使用 Windows 7 和 git bash 最新版本

编辑：我不想删除这个分支。

【问题讨论】：

文件.git/HEAD的内容是什么？它是否指向有效的分支名称？分支名称是否指向有效的提交哈希？

标签： git git-branch fatal-error git-log blue-screen-of-death

【解决方案1】：

我在 Windows 7 上遇到了类似的问题。在我的情况下，\.git\refs\heads 下的当前分支文件（由./git/HEAD 引用）已损坏。

我在.git\logs\refs\heads 上找到了当前分支的哈希码，具有相同的分支名称。

我通过记事本打开该文件 (.git\logs\refs\heads\xxx) 并将第四个数字（哈希码）复制到 (.git\refs\heads\xxx) 解决了这个问题

【讨论】：

.git 文件夹在我的情况下是隐藏的，你自己看看。
谢谢！我发现检查提交哈希以查看它是否是我要使用 git checkout <hash> 恢复的状态也很有用（在将其复制到 git/refs/heads/xxx 之前）
谢谢，它成功了。我将最后一个提交哈希表 .git\logs\refs\heads\xxx 复制到 .git\refs\heads\xxx。日志中有两列哈希码，第二列的最后一条是我的最后一次提交。
非常感谢，效果很好。总有一天我会仔细研究 git 的内部结构
谢谢老哥，成功了。其实我只是从 .git\logs\refs\heads\xxx 的最后一行复制第二个哈希码到 .git\refs\heads\xxx

【解决方案2】：

.git\refs\heads 目录中的文件是你的分支。检查那些文件。它们应该只包含一个提交对象的 SHA-1 哈希。此哈希是您最新提交的 SHA-1 密钥和您的 HEAD。

复制 SHA-1 密钥并键入

$ git cat-file -t 5917fefd485f655ab369d4e9eeda3c157c03f514
commit

$ git cat-file -p 5917fefd485f655ab369d4e9eeda3c157c03f514
tree b75cab3c54b780075b312be3e878b389a2baf904
parent 8235189aa22169295243d295fb1cc2ff2f8f7cd5
author Ilker Cat <ilker.cat@blabla.com> 1495136738 +0200
committer Ilker Cat <ilker.cat@blabal.com> 1495136738 +0200

第二个输出是提交对象基本上包含的内容。尝试检查 .git\refs\heads\master 下 master 分支中的提交对象及其树和父 SHA-1 密钥是否未损坏。

即使您的主分支文件中的一些撇号也会导致“损坏的分支”。它必须只包含最新的提交对象 SHA-1 哈希，不能包含其他任何内容。

【讨论】：

【解决方案3】：

如果您尝试将分支重命名为命名空间（或文件夹）分支，则可能会遇到此错误。

如果发生这种情况，请转到目录 .git/logs/refs/heads/<name> 和 .git/refs/heads/<name> ，您会看到您的分支现在是一个文件夹，其中包含一个文件。

在这两个文件夹中，将文件移出到文件夹级别，签出该分支，删除现在为空的文件夹，现在您应该能够正确执行 git checkout -b <name>/<subname> 或 git branch -M <name>/<subname>。

【讨论】：

非常感谢。差点心脏病发作！
我希望我能理解为什么这会奏效，但它确实奏效了。（我没有尝试重命名我的分支，我的电脑在拉取时崩溃了）

【解决方案4】：

我通过将 repo 克隆到一个新文件夹然后替换更改的文件来解决它。似乎不是一个好的解决方案，但它是安全的！

【讨论】：

【解决方案5】：

有时也可能是因为文件权限问题，请检查你是否对仓库下的所有文件都有适当的权限。

【讨论】：

是的，但在这种情况下，我是唯一的用户；拥有所有权利！

【解决方案6】：

你的分支名称现在可能包含一些特殊字符或类似的东西。

您应该转到结帐的根目录（.git/ 目录所在的位置）并

列表项编辑.git/packed-refs;如果您看到带有您的分支名称的行，则将其删除
查看.git/refs/heads for一个以你的分支命名的文件；如果你看到一个，删除它

【讨论】：

在执行此操作后，它似乎只将我的文件视为“所有文件都是新的”：\

【解决方案7】：

在使用记事本打开以我在.git\logs\refs\heads\<MY-CORRUPTED-BRANCH> 找到的分支名称命名的文件后，可能会出现空文件。所以我删了。

并运行以获取最新的提交

git reflog

4404dd7 HEAD@{0}：提交：更新自述文件

然后我跑

git reset --hard 4404dd7

HEAD 现在位于 4404dd7 更新自述文件

分支又回来了。注意

这可能会分散您的分支。所以你可能需要稍后修复它们。

4404dd7 是我在该分支中的最新提交，我不知道这是否是正确的解决方案，但它对我有用。

【讨论】：

【解决方案8】：

遇到了同样的问题。删除 .git\refs\heads\ 为我解决了这个问题。

【讨论】：

【解决方案9】：

我遇到了同样的问题。我刚刚删除了.git/refs/heads里面的所有文件，然后我尝试编辑我的一个文件以便 git 接受提交。然后，当我推送我的文件时，我收到了这个错误：

10:47 推送被拒绝由于更新过程中发生冲突，推送已被取消。检查冲突是否已正确解决，然后再次调用 push。

但是，我在合并文件时通过接受 rebase 选项解决了这个问题，没有冲突。

【讨论】：

【解决方案10】：

好吧，这个问题，我发现，如果您返回并克隆您的存储库，您只需从新存储库中复制 .git 文件夹并替换旧存储库中的 .git 文件夹即可。

剩下的就是历史：运行 git add 。然后 git commit 并推送。

【讨论】：