2023年1月更新:(八年后)

使用GitHub CLI gh v2.22.0(2023年1月)，您可以从本地克隆的GitHub存储库中搜索:

参见gh search commit:

例子:

# search commits matching set of keywords "readme" and "typo"
$ gh search commits readme typo

# search commits matching phrase "bug fix"
$ gh search commits "bug fix"

# search commits committed by user "monalisa"
$ gh search commits --committer=monalisa

2017年1月更新(两年后):

您现在可以搜索提交消息!(仍然只在主分支中)

2015年2月:考虑到目前基于Elasticsearch(2013年1月引入)的搜索基础设施，不确定这是否可能实现。

作为“来自可信和/或官方来源”的答案，以下是对GitHub负责引入Elasticsearch的人员的采访(2013年8月)。

Tim Pease: We have two document types in there: One is a source code file and the other one is a repository. The way that git works is you have commits and you have a branch for each commit. Repository documents keep track of the most recent commit for that particular repository that has been indexed. When a user pushes a new commit up to Github, we then pull that repository document from elasticsearch. We then see the most recently indexed commit and then we get a list of all the files that had been modified, or added, or deleted between this recent push and what we have previously indexed. Then we can go ahead and just update those documents which have been changed. We don’t have to re-index the entire source code tree every time someone pushes. Andrew Cholakian: So, you guys only index, I’m assuming, the master branch. Tim Pease: Correct. It’s only the head of the master branch that you’re going to get in there and still that’s a lot of data, two billion documents, 30 terabytes. Andrew Cholakian: That is awesomely huge.

[...]

Tim Pease: With indexing source code on push, it’s a self-healing process. We have that repository document which keeps track of the last indexed commit. If we missed, just happen to miss three commits where those jobs fail, the next commit that comes in, we’re still looking at the diff between the previous commit that we indexed and the one that we’re seeing with this new push. You do a git diff and you get all the files that have been updated, deleted, or added. You can just say, “Okay, we need to remove these files. We need to add these files, and all that.” It’s self-healing and that’s the approach that we have taken with pretty much all of the architecture.

这意味着并非所有回购的所有分支都将使用该方法进行索引。 目前无法使用全局提交消息搜索。 Tim Pease本人也确认提交消息没有被索引。

注意，获得本地克隆的自己的elasticsearch本地索引并不是不可能的:参见“用elasticsearch搜索git存储库”

但对于特定的回购，最简单的方法仍然是克隆它，并执行以下操作:

git log --all --grep='my search'

(更多选项在“如何通过提交消息搜索Git存储库?”)

2023年1月更新:(八年后)

使用GitHub CLI gh v2.22.0(2023年1月)，您可以从本地克隆的GitHub存储库中搜索:

参见gh search commit:

例子:

# search commits matching set of keywords "readme" and "typo"
$ gh search commits readme typo

# search commits matching phrase "bug fix"
$ gh search commits "bug fix"

# search commits committed by user "monalisa"
$ gh search commits --committer=monalisa

2017年1月更新(两年后):

您现在可以搜索提交消息!(仍然只在主分支中)

2015年2月:考虑到目前基于Elasticsearch(2013年1月引入)的搜索基础设施，不确定这是否可能实现。

作为“来自可信和/或官方来源”的答案，以下是对GitHub负责引入Elasticsearch的人员的采访(2013年8月)。

Tim Pease: We have two document types in there: One is a source code file and the other one is a repository. The way that git works is you have commits and you have a branch for each commit. Repository documents keep track of the most recent commit for that particular repository that has been indexed. When a user pushes a new commit up to Github, we then pull that repository document from elasticsearch. We then see the most recently indexed commit and then we get a list of all the files that had been modified, or added, or deleted between this recent push and what we have previously indexed. Then we can go ahead and just update those documents which have been changed. We don’t have to re-index the entire source code tree every time someone pushes. Andrew Cholakian: So, you guys only index, I’m assuming, the master branch. Tim Pease: Correct. It’s only the head of the master branch that you’re going to get in there and still that’s a lot of data, two billion documents, 30 terabytes. Andrew Cholakian: That is awesomely huge.

[...]

Tim Pease: With indexing source code on push, it’s a self-healing process. We have that repository document which keeps track of the last indexed commit. If we missed, just happen to miss three commits where those jobs fail, the next commit that comes in, we’re still looking at the diff between the previous commit that we indexed and the one that we’re seeing with this new push. You do a git diff and you get all the files that have been updated, deleted, or added. You can just say, “Okay, we need to remove these files. We need to add these files, and all that.” It’s self-healing and that’s the approach that we have taken with pretty much all of the architecture.

这意味着并非所有回购的所有分支都将使用该方法进行索引。 目前无法使用全局提交消息搜索。 Tim Pease本人也确认提交消息没有被索引。

注意，获得本地克隆的自己的elasticsearch本地索引并不是不可能的:参见“用elasticsearch搜索git存储库”

但对于特定的回购，最简单的方法仍然是克隆它，并执行以下操作:

git log --all --grep='my search'

(更多选项在“如何通过提交消息搜索Git存储库?”)

你过去可以这样做，但GitHub在2013年年中的某个时候删除了这个功能。要在本地实现这一点，您可以这样做:

git log -g --grep=STRING

(如果您想搜索其他分支和悬空提交，请使用-g标志。)

-g, --walk-reflogs
    Instead of walking the commit ancestry chain, walk reflog entries from
    the most recent one to older ones.

简单的回答是，你不能直接在github.com网站上搜索提交消息。目前，我们推荐这个线程中其他人提出的本地git grep解决方案。

在某个时间点上，GitHub确实为单个存储库提供了git grep风格的提交消息搜索。不幸的是，这种方法暴露了拒绝服务，可能导致文件服务器不可访问。出于这个原因，我们删除了git grep搜索。

目前粗略估计，GitHub的提交次数大约在800亿次左右。尽管谷歌的工程师们在背后嘲笑我们，但这在ElasticSearch中存储的文档数量相当大。我们很想让这个数据集可以搜索，但这不是一个微不足道的项目。

到2017年，GitHub本身就包含了这个功能。

他们使用的示例搜索是repo:torvalds/linux merge:false加密策略

GIF图片来自https://github.com/blog/2299-search-commit-messages

如果你有一个本地版本的存储库，你可能想尝试一下我写的这个粗糙的shell脚本，它可以在默认浏览器的新选项卡中打开与你的搜索词匹配的所有提交的GitHub页面:

#!/bin/sh
for sha1 in $(git rev-list HEAD -i --grep="$1"); do
    python -mwebbrowser https://github.com/RepoOwnerUserName/RepoName/commit/$sha1 >/dev/null 2>/dev/null
done

只需将https://github.com/RepoOwnerUserName/RepoName/替换为你仓库的实际GitHub URL，将脚本保存在某个地方(例如githubsearch.sh，使其可执行(chmod +x githubsearch.sh)，然后将以下别名添加到你的~/。bashrc文件:(

alias githubsearch='/path/to/githubsearch.sh'

然后，在Git存储库的任何地方，在终端上执行以下操作:

githubsearch "what you want to search for"

任何与你的搜索词(不区分大小写)匹配的提交都会在你的浏览器中打开相应的GitHub页面。(请注意，如果你的搜索词出现在数百次提交中，这可能会使你的浏览器崩溃，并在一段时间内吃掉你的电脑CPU。)