我遇到了一些分支问题，最终在 GitHub 和本地删除了与该分支相关的所有内容，但我不断收到：
$ git branch
warning: ignoring ref with broken name refs/heads/deleted_branch (conflicted copy 2020-12-18 151952)
我已经完成了git branch -d deleted_branch、git branch -D deleted_branch，删除了 GitHub 上的分支（后面是 fetch 和 pull），但 deleted_branch 似乎还在。我该如何解决这个问题？
谢谢！
【问题讨论】：
这个名字：
deleted_branch (conflicted copy 2020-12-18 151952)
看起来像是 Dropbox 等共享系统创建的那种东西。
Git 需要完全控制自己的存储库。 永远不要将 Git 存储库放在共享文件夹中。1Git 有自己的机制来进行适当控制的共享，我们通过 git fetch 和 git push 实现了这一点。 （您可以将git fetch 隐藏在git pull 后面，但它仍然是git fetch。）
我如何[删除错误的分支名称]？
坏名不是deleted_branch，而是deleted branch (conflicted copy 2020-12-18 151952)。删除它的唯一方法可能是手动执行。
不过，首先，请确保 Git 存储库不受所有非 Git 程序的影响，这些程序可能会自动调整它并尝试解决冲突的文件副本。换句话说，获取任何共享文件夹的 Git 存储库out。请注意，正确的 Git 存储库通常位于工作树顶层的 .git 子目录（子文件夹）中。如果您移动整个工作树，包括其所有子文件夹，那么 Git 存储库也会随之移动。
现在您可以尝试git branch -d "deleted branch (conflicted copy 2020-12-18 151952)"，其中双引号可保护您的外壳中的括号和空格。如果这行得通，那很好。如果没有，您将需要手动方法。
您可以输入存储库本身：.git 文件夹。在此文件夹（目录）内，有一个名为refs 的子文件夹。在其中还有另一个名为heads 的子目录。第二个子目录包含每个“活动”分支的文件。列出目录的内容应该会出现坏名。例如，在我的一台机器上的一个好的 Git 存储库中，我得到：
$ ls -l .git/refs/heads
total 4
-rw-r--r-- ... 41 Dec 13 07:47 master
（此存储库只有一个活动分支，名为master）。请注意，我实际上并没有费心进入.git 目录；我从工作树的顶层执行这些操作，使用 .git/refs/ 访问那里的文件。
如果坏名出现在这里：
-rw-r--r-- ... 41 <date> deleted_branch (conflicted copy 2020-12-18 151952)
然后您可以使用系统的文件删除工具将其删除。在这个盒子（Linux/Unix-like）上，这是rm：
$ rm ".git/refs/heads/deleted_branch (conflicted copy 2020-12-18 151952)"
引号保护括号和空格不受外壳程序影响，以便rm 命令获取整个名称。这将删除包含分支哈希 ID 的内部文件 - 它们每个长 40 个字节，这就是为什么大小为 41 个字节：40 个字节加上换行符 - 并且删除了文件，分支现在应该消失了。
如果它没有消失或者一开始就不存在，那么 Git 也有可能“打包”了 ref。在这种情况下，在不会破坏内容的文本编辑器中打开文件.git/packed-refs（不会将其转换为 UTF-16-LE，也不会添加字节顺序标记，也不会将行尾更改为 CRLF 而不是仅 LF 等）。删除与错误分支名称对应的行并保存文件（仍为纯文本）。
1什么，从来没有？ 在极少数情况下可以执行此操作，只要您确切知道自己在做什么以及 Git 内部如何工作，但即便如此，它通常也是馊主意。我已经用 VirtualBox 虚拟机做了一个实验，它可以工作，但有时它会变得很慢——太慢了，最好只使用 Git 的 fetch/push 系统。
【讨论】：