除了在所有树中搜索直到找到匹配的哈希值之外，没有。

作为一个实验，我制作了一个提交后挂钩，它在提交元数据中存储关于当前签出的分支的信息。我还略微修改了gitk以显示该信息。

你可以在这里查看：https://github.com/pajp/branch-info-commits

简单的答案是Git不存储提交的分支的名称。试图重建这些信息的技巧似乎在所有情况下都不起作用。

khichar.anil在回答中涵盖了大部分内容。

我只是添加了一个标志，它将从修订名称列表中删除标记。这给了我们：

git name-rev --name-only --exclude=tags/* $SHA

2013年12月更新：

sschuberth注释

gitwhat分支（Perl脚本，见下文）似乎不再被维护。合并时的git是一种用Python编写的替代方法，对我来说非常有用。

它基于“查找包含特定提交的合并提交”。

git when-merged [OPTIONS] COMMIT [BRANCH...]

查找提交合并到一个或多个分支的时间。查找将commit带入指定BRANCH的合并提交。具体来说，在包含commit作为祖先的BRANCH的第一个父历史上查找最早的提交。

原答复2010年9月：

Sebastien Douche刚刚推了推（在这个SO回答之前16分钟）：

gitwhatbranch：发现提交所在的分支，或者它是如何到达命名分支的

这是Seth Robertson的Perl脚本，看起来很有趣：

简介

git-what-branch [--allref] [--all] [--topo-order | --date-order ]
[--quiet] [--reference-branch=branchname] [--reference=reference]
<commit-hash/tag>...

概述告诉我们（默认情况下）提交和合并的最早因果路径，以使请求的提交到达指定的分支。如果直接在指定的分支上进行提交，那么这显然是最早的路径。所谓最早的因果路径，我们指的是最早合并到命名分支的路径，即提交时间（除非指定了拓扑顺序）。性能如果许多分支（例如数百个）包含提交，系统可能需要很长时间（对于Linux树中的特定提交，探索一个分支需要8秒，但有超过200个候选分支）来跟踪每个提交的路径。选择要检查的特定引用分支引用标记将快数百倍（如果您有数百个候选分支）。示例

 # git-what-branch --all 1f9c381fa3e0b9b9042e310c69df87eaf9b46ea4
 1f9c381fa3e0b9b9042e310c69df87eaf9b46ea4 first merged onto master using the following minimal temporal path:
   v2.6.12-rc3-450-g1f9c381 merged up at v2.6.12-rc3-590-gbfd4bda (Thu May  5 08:59:37 2005)
   v2.6.12-rc3-590-gbfd4bda merged up at v2.6.12-rc3-461-g84e48b6 (Tue May  3 18:27:24 2005)
   v2.6.12-rc3-461-g84e48b6 is on master
   v2.6.12-rc3-461-g84e48b6 is on v2.6.12-n
   [...]

该程序不考虑樱桃选择感兴趣的提交的影响，只考虑合并操作。

gitbranch--contains<ref>是最明显的“瓷”命令。如果您只想使用“管道”命令执行类似的操作：

COMMIT=$(git rev-parse <ref>) # expands hash if needed
for BRANCH in $(git for-each-ref --format "%(refname)" refs/heads); do
  if $(git rev-list $BRANCH | fgrep -q $COMMIT); then
    echo $BRANCH
  fi
done

（此SO答案的交叉点）