注意：这个是重复的，但是另一个问题没有被接受的答案，所以我在这里发布一个。出现问题是因为有人创建了一个分支（在上面的示例中为feature/SOMETHING-1234），该分支仅在情况与您的 Git 已经选择的名称不同。例如，您可能拥有feature/something-1234 或FEATURE/SOMETHING-1234，而他们现在拥有feature/SOMETHING-1234。
Git 认为仅大小写不同的名称，例如 a 与 A，是不同的名称。这在某些时候可以正常工作。它在某些操作系统上会失败1有时。当它失败时——就像你的情况一样——你会出现像你现在看到的那种奇怪的症状。
在这种情况下，可能治愈它的一种方法是删除（本地）文件.git/refs/remotes/origin/feature/something-1234——你可以用全小写的形式输入它，不管任何部分有大写-案子;见脚注 1——就在你运行 git fetch 之前。您的 Git 将使用另一个 Git 提供的案例重新创建它。但是请注意，问题很可能会再次出现，甚至可能立即出现，特别是如果另一个 Git 是 可以 存储 both 名称的 Git（例如，feature/something-1234和 feature/SOMETHING-1234) 在任何时候。
为了更持久地解决问题，有必要删除 other Git 中的重复的例外情况名称。也就是说，如果 GitHub Git 有名为 feature/SOMETHING-1234 和 feature/something-1234 的分支，您和您的同事必须聚在一起，就保留这两个名称中的哪个名称以及删除哪个名称达成一致。然后你可以而且应该删除“错误”的，并确保永远不要重新创建它。
（我认为，Git 中正在进行的工作将为每个人解决这个问题，但它尚未发布。）
1从技术上讲，这是目前文件系统特定问题，而不是操作系统特定问题。但是，它通常发生在 Windows 和 MacOS 文件系统上，这些文件系统设置为保留大小写但折叠大小写。也就是说，如果您创建了一个名为ReadMe 的文件，然后要求系统打开一个名为readme 或README 的文件，它会打开现有的ReadMe 文件。
其他文件系统（包括 Linux 主机上常用的文件系统，例如运行 GitHub 的文件系统）将 readme、ReadMe 和 README 视为三个不同的文件。因此，这些系统可以并且将同时存储所有三个文件。 Windows 和 MacOS 上的折叠文件系统实际上不能存储三个这样的文件。
Git 当前使用混合方案，其中 refs 或 references（分支、标记和其他名称）存储在两个位置之一或两个位置：一个简单的纯文本表文件，它在一行上包含每个引用及其哈希 ID，或者每个文件一个哈希 ID，文件的 name 与引用名称匹配。当 refs 只是大小写不同时，每个文件的存储机制只能在可以存储两个名称的文件系统上正常工作。不过，即使在通常的 Windows 和 MacOS 文件系统上，one-big-file 机制也能正常工作，因为所有条目都位于名为 .git/packed-refs 的文件中。
请注意，如果引用同时出现在.git/packed-refs 和单个文件中，则单个文件版本会覆盖.git/packed-refs 版本。