GitHub入门（2）

最新推荐文章于 2024-07-31 13:57:32 发布

BigYellowHsw

最新推荐文章于 2024-07-31 13:57:32 发布

阅读量620

点赞数 1

分类专栏：工具类

工具类专栏收录该内容

5 篇文章 0 订阅

订阅专栏

【学习自AndroidDeveloper】

Git 进阶知识

1. 用户名和邮箱

我们知道我们进行的每一次commit都会产生一条log，这条log标记了提交人的姓名与邮箱，以便其他人方便的查看与联系提交人，所以我们在进行提交代码的第一步就是要设置自己的用户名与邮箱。执行以下代码：

git config --global user.name "stormzhang"
git config --global user.email "stormzhang.dev@gmail.com"

以上进行了全局配置，当然有些时候我们的某一个项目想要用特定的邮箱，这个时候只需切换到你的项目，以上代码把 –global 参数去除，再重新执行一遍就ok了。

PS：我们在 GitHub 的每次提交理论上都会在主页的下面产生一条绿色小方块的记录，如果你确认你提交了，但是没有绿色方块显示，那肯定是你提交代码配置的邮箱跟你 GitHub 上的邮箱不一致，GitHub 上的邮箱可以到 Setting -> Emails里查看。

2. alias

我们知道我们执行的一些Git命令其实操作很频繁的类似有：

git commit
git checkout
git branch
git status
...

这些操作非常频繁，每次都要输入完全是不是有点麻烦，有没有一种简单的缩写输入呢？比如我对应的直接输入以下：

git c
git co
git br
git s
...

是不是很简单快捷啊？这个时候就用到了alias配置了，翻译过来就是别名的意思，输入以下命令就可以直接满足了以上的需求。

git config --global alias.co checkout  # 别名
git config --global alias.ci commit
git config --global alias.st status
git config --global alias.br branch

当然以上别名不是固定的，你完全可以根据自己的习惯去定制，除此之外还可以设置组合，比如：

git config --global alias.psm 'push origin master'
git config --global alias.plm 'pull origin master'

之后经常用到的git push origin master 和 git pull origin master 直接就用 git psm 和 git plm 代替了，是不是很方便？

另外这里给大家推荐一个很强大的 alias 命令，我们知道我们输入 git log 查看日志的时候是类似这样的：

告诉大家一个比较屌的命令，输入git log –graph –pretty=format:’%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset’ –abbrev-commit –date=relative 然后日志这样了：

是不是比较清晰，整个分支的走向也很明确，但是每次都要输这么一大串是不是也很烦？这时候你就该想到 alias 啊：

git config --global alias.lg "log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative"

这样以后直接输入 git lg 就行了。

3. 其他配置

当然还有一些其他有用的配置，默认情况下 git 用的编辑器是 vi ，如果不喜欢可以改成其他编辑器，比如我习惯 vim 。

git config --global core.editor "vim"  # 设置Editor使用vim

你们如果喜欢其他编辑器可自行搜索配置，前提是本机有安装。

有些人纳闷我的终端怎么有各种颜色，自己却不是这样的，那是因为你们没有开启给 Git 着色，输入如下命令即可：

git config --global color.ui true

还有些其他的配置如：

git config --global core.quotepath false # 设置显示中文文件名

以上基本所有的配置就差不多了，默认这些配置都在 ~/.gitconfig 文件下的，你可以找到这个文件查看自己的配置，也可以输入 git config -l 命令查看。

4. diff

diff命令算是很常用的，使用场景是我们经常在做代码改动，但是有的时候2天前的代码了，做了哪些改动都忘记了，在提交之前需要确认下，这个时候就可以用diff来查看你到底做了哪些改动，举个例子，比如我有一个 a.md 的文件，我现在做了一些改动，然后输入 git diff 就会看到如下：

红色的部分前面有个 - 代表我删除的，绿色的部分前面有个 + 代表我增加的，所以从这里你们很一目了然的知道我到底对这个文件做了哪些改动。

值得一提的是直接输入 git diff 只能比较当前文件和暂存区文件差异，什么是暂存区？就是你还没有执行 git add 的文件。

当然跟暂存区做比较之外，他还可以有其他用法，如比较两次 commit 之间的差异，比较两个分支之间的差异，比较暂存区和版本库之间的差异等，具体用法如下：

git diff <$id1> <$id2>   # 比较两次提交之间的差异
git diff <branch1>..<branch2> # 在两个分支之间比较 
git diff --staged   # 比较暂存区和版本库差异

5. checkout

我们知道 checkout 一般用作切换分支使用，比如切换到 develop 分支，可以执行：

git checkout develop

但是 checkout 不只用作切换分支，他可以用来切换tag，切换到某次commit，如：

git checkout v1.0
git checkout ffd9f2dd68f1eb21d36cee50dbdd504e95d9c8f7 # 后面的一长串是commit_id，是每次commit的SHA1值，可以根据 git log 看到。

除了有“切换”的意思，checkout 还有一个撤销的作用，举个例子，假设我们在一个分支开发一个小功能，刚写完一半，这时候需求变了，而且是大变化，之前写的代码完全用不了了，好在你刚写，甚至都没有 git add 进暂存区，这个时候很简单的一个操作就直接把原文件还原：

git checkout a.md

这里稍微提下，checkout 命令只能撤销还没有 add 进暂存区的文件。

6. stash

设想一个场景，假设我们正在一个新的分支做新的功能，这个时候突然有一个紧急的bug需要修复，而且修复完之后需要立即发布。当然你说我先把刚写的一点代码进行提交不就行了么？这样理论上当然是ok的，但是这会产品垃圾commit，原则上我们每次的commit都要有实际的意义，你的代码只是刚写了一半，还没有什么实际的意义是不建议就这样commit的，那么有没有一种比较好的办法，可以让我暂时切到别的分支，修复完bug再切回来，而且代码也能保留的呢？

这个时候 stash 命令就大有用处了，前提是我们的代码没有进行 commit ，哪怕你执行了 add 也没关系，我们先执行

git stash

命令，什么意思呢？意思就是把当前分支所有没有 commit 的代码先暂存起来，这个时候你再执行 git status 你会发现当前分支很干净，几乎看不到任何改动，你的代码改动也看不见了，但其实是暂存起来了。执行

git stash list

你会发现此时暂存区已经有了一条记录。

这个时候你可以切换会其他分支，赶紧把bug修复好，然后发布。之后一切都解决了，你再切换回来继续做你之前没做完的功能，但是之前的代码怎么还原呢？

git stash apply

你会发现你之前的代码全部又回来了，就好像一切都没发生过一样，紧接着你最好需要把暂存区的这次 stash 记录删除，执行：

git stash drop

就把最近一条的 stash 记录删除了，是不是很方便？其实还有更方便的，你可以使用：

git stash pop

来代替 apply 命令，pop 跟 apply 的唯一区别就是 pop 不但会帮你把代码还原，还自动帮你把这条 stash 记录删除，省的自己再 drop 一次了，为了验证你可以紧接着执行 git stash list 命令来确认是不是已经没有记录了。

最后还有一个命令介绍下：

git stash clear

就是清空所有暂存区的记录，drop 是只删除一条，当然后面可以跟 stash_id 参数来删除指定的某条记录，不跟参数就是删除最近的，而 clear 是清空。

7. merge & rebase

我们知道 merge 分支是合并的意思，我们在一个 featureA 分支开发完了一个功能，这个时候需要合并到主分支 master 上去，我们只需要进行如下操作：

git checkout master
git merge featureA

其实 rebase 命令也是合并的意思，上面的需求我们一样可以如下操作：

git checkout master
git rebase featureA

rebase 跟 merge 的区别你们可以理解成有两个书架，你需要把两个书架的书整理到一起去，第一种做法是 merge ，比较粗鲁暴力，就直接腾出一块地方把另一个书架的书全部放进去，虽然暴力，但是这种做法你可以知道哪些书是来自另一个书架的；第二种做法就是 rebase ，他会把两个书架的书先进行比较，按照购书的时间来给他重新排序，然后重新放置好，这样做的好处就是合并之后的书架看起来很有逻辑，但是你很难清晰的知道哪些书来自哪个书架的。

只能说各有好处的，不同的团队根据不同的需要以及不同的习惯来选择就好。

8. 解决冲突

假设这样一个场景，A和B两位同学各自开了两个分支来开发不同的功能，大部分情况下都会尽量互不干扰的，但是有一个需求A需要改动一个基础库中的一个类的方法，不巧B这个时候由于业务需要也改动了基础库的这个方法，因为这种情况比较特殊，A和B都认为不会对地方造成影响，等两人各自把功能做完了，需要合并的到主分支 master 的时候，我们假设先合并A的分支，这个时候没问题的，之后再继续合并B的分支，这个时候想想也知道就有冲突了，因为A和B两个人同时更改了同一个地方，Git 本身他没法判断你们两个谁更改的对，但是这个时候他会智能的提示有 conflicts ，需要手动解决这个冲突之后再重新进行一次 commit 提交。我随便在项目搞了一个冲突做下示例：

以上截图里就是冲突的示例，冲突的地方由 ==== 分出了上下两个部分，上部分一个叫 HEAD 的字样代表是我当前所在分支的代码，下半部分是一个叫 baidu_activity 分支的代码，可以看到 HEAD 对 gradle 插件进行了升级，同时新增了一个插件，所以我们很容易判断哪些代码该保留，哪些代码该删除，我们只需要移除掉那些老旧代码，而且同时也要把那些 <<< HEAD、==== 以及 >>>>>>baidu_activity 这些标记符号也一并删除，最后进行一次 commit 就ok了。

我们在开发的过程中一般都会约定尽量大家写的代码不要彼此影响，以减少出现冲突的可能，但是冲突总归无法避免的，我们需要了解并掌握解决冲突的方法。

团队合作利器 Branch

Git 相比于 SVN 最强大的一个地方就在于「分支」，Git 的分支操作简直不要太方便，而实际项目开发中团队合作最依赖的莫过于分支了，关于分支前面的系列也提到过，但是本篇会详细讲述什么是分支、分支的具体操作以及实际项目开发中到底是怎么依赖分支来进行团队合作的。

1. 什么是分支？

我知道读者中肯定有些人对分支这个概念比较模糊，其实你们可以这么理解，你们几个人一起去旅行，中间走到一个三岔口，每条路可能有不同的风景，你们约定 3 天之后在某地汇聚，然后各自出发了。而这三条分叉路就可以理解成你们各自的分支，而等你们汇聚的时候相当于把你们的分支进行了合并。

2. 分支的常用操作

通常我们默认都会有一个主分支叫 master ，下面我们先来看下关于分支的一些基本操作：

新建一个叫 develop 的分支

git branch develop

这里稍微提醒下大家，新建分支的命令是基于当前所在分支的基础上进行的，即以上是基于 mater 分支新建了一个叫做 develop 的分支，此时 develop 分支跟 master 分支的内容完全一样。如果你有 A、B、C三个分支，三个分支是三位同学的，各分支内容不一样，如果你当前是在 B 分支，如果执行新建分支命令，则新建的分支内容跟 B 分支是一样的，同理如果当前所在是 C 分支，那就是基于 C 分支基础上新建的分支。

切换到 develop 分支

git checkout develop

如果把以上两步合并，即新建并且自动切换到 develop 分支：

git checkout -b develop

把 develop 分支推送到远程仓库

git push origin develop

如果你远程的分支想取名叫 develop2 ，那执行以下代码：

git push origin develop:develop2

但是强烈不建议这样，这会导致很混乱，很难管理，所以建议本地分支跟远程分支名要保持一致。

查看本地分支列表

git branch

查看远程分支列表

git branch -r

删除本地分支

git branch -d develop

git branch -D develop (强制删除)

删除远程分支

git push origin :develop

如果远程分支有个 develop ，而本地没有，你想把远程的 develop 分支迁到本地：

git checkout develop origin/develop

同样的把远程分支迁到本地顺便切换到该分支：

git checkout -b develop origin/develop

3. 基本的团队协作流程

一般来说，如果你是一个人开发，可能只需要 master、develop 两个分支就 ok 了，平时开发在 develop 分支进行，开发完成之后，发布之前合并到 master 分支，这个流程没啥大问题。

如果你是 3、5 个人，那就不一样了，有人说也没多大问题啊，直接可以新建 A、B、C 三个人的分支啊，每人各自开发各自的分支，然后开发完成之后再逐步合并到 master 分支。然而现实却是，你正在某个分支开发某个功能呢，这时候突然发现线上有一个很严重的 bug ，不得不停下手头的工作优先处理 bug ，而且很多时候多人协作下如果没有一个规范，很容易产生问题，所以多人协作下的分支管理规范很重要，就跟代码规范一样重要，以下就跟大家推荐一种我们内部在使用的一种分支管理流程 Git Flow。

4. Git Flow

准确的说 Git Flow 是一种比较成熟的分支管理流程，我们先看一张图能清晰的描述他整个的工作流程：

第一次看上面那个图是不是一脸懵逼？跟我当时一样，不急，我来用简单的话给你们解释下。

一般开发来说，大部分情况下都会拥有两个分支 master 和 develop，他们的职责分别是：

master：永远处在即将发布(production-ready)状态

develop：最新的开发状态

确切的说 master、develop 分支大部分情况下都会保持一致，只有在上线前的测试阶段 develop 比 master 的代码要多，一旦测试没问题，准备发布了，这时候会将 develop 合并到 master 上。

但是我们发布之后又会进行下一版本的功能开发，开发中间可能又会遇到需要紧急修复 bug ，一个功能开发完成之后突然需求变动了等情况，所以 Git Flow 除了以上 master 和 develop 两个主要分支以外，还提出了以下三个辅助分支：

feature: 开发新功能的分支, 基于 develop, 完成后 merge 回 develop

release: 准备要发布版本的分支, 用来修复 bug，基于 develop，完成后 merge 回 develop 和 master

hotfix: 修复 master 上的问题, 等不及 release 版本就必须马上上线. 基于 master, 完成后 merge 回 master 和 develop

什么意思呢？

举个例子，假设我们已经有 master 和 develop 两个分支了，这个时候我们准备做一个功能 A，第一步我们要做的，就是基于 develop 分支新建个分支：

git branch feature/A

看到了吧，其实就是一个规范，规定了所有开发的功能分支都以 feature 为前缀。

但是这个时候做着做着发现线上有一个紧急的 bug 需要修复，那赶紧停下手头的工作，立刻切换到 master 分支，然后再此基础上新建一个分支：

git branch hotfix/B

代表新建了一个紧急修复分支，修复完成之后直接合并到 develop 和 master ，然后发布。

然后再切回我们的 feature/A 分支继续着我们的开发，如果开发完了，那么合并回 develop 分支，然后在 develop 分支属于测试环境，跟后端对接并且测试的差不多了，感觉可以发布到正式环境了，这个时候再新建一个 release 分支：

git branch release/1.0

这个时候所有的 api、数据等都是正式环境，然后在这个分支上进行最后的测试，发现 bug 直接进行修改，直到测试 ok 达到了发布的标准，最后把该分支合并到 develop 和 master 然后进行发布。

以上就是 Git Flow 的概念与大概流程，看起来很复杂，但是对于人数比较多的团队协作现实开发中确实会遇到这么复杂的情况，是目前很流行的一套分支管理流程，但是有人会问每次都要各种操作，合并来合并去，有点麻烦，哈哈，这点 Git Flow 早就想到了，为此还专门推出了一个 Git Flow 的工具，并且是开源的：

GitHub 开源地址：https://github.com/nvie/gitflow

简单点来说，就是这个工具帮我们省下了很多步骤，比如我们当前处于 master 分支，如果想要开发一个新的功能，第一步切换到 develop 分支，第二步新建一个以 feature 开头的分支名，有了 Git Flow 直接如下操作完成了：

git flow feature start A

这个分支完成之后，需要合并到 develop 分支，然而直接进行如下操作就行：

git flow feature finish A

如果是 hotfix 或者 release 分支甚至会自动帮你合并到 develop、master 两个分支。

GitHub 常见的几种操作

我们都说开源社区最大的魅力是人人多可以参与进去，发挥众人的力量，让一个项目更完善，更强壮。那么肯定有人疑问，我自己目前还没有能力开源一个项目，但是想一起参与到别的开源项目中，该怎么操作呢？那么今天，就来给大家一起介绍下 GitHub 上的一些常见的操作，看完之后你就知道方法了。

我们姑且以 Square 公司开源的 Retrofit 为例来介绍。

打开链接：https://github.com/square/retrofit

然后看到如下的项目主页：

可以看到一个项目可以进行的操作主要就是两部分，第一部分包括 Watch、Star、Fork ，这三个操作之前的系列介绍过了，这里就不啰嗦了。

我们着重来介绍第二部分，分别包括 Code、Issues、Pull requests、Projects、Wiki、Pulse、Graphs。接下来我们来一个个解释下。

Code

这个好理解，就是你项目的代码文件而已，这里说明一下，每个项目通常都会有对该项目的介绍，只需要在项目的根目录里添加一个 README.md 文件就可以，使用 markdown 语法，GitHub 自动会对该文件进行渲染。

Issues

Issues 代表该项目的一些问题或者 bug，并不是说 Issues 越少越好，Issues 被解决的越多说明项目作者或者组织响应很积极，也说明该开源项目的作者很重视该项目。我们来看下 Retrofit 的 Issues 主页，截至目前 close（解决）了 1305 个 Issue，open （待解决）状态的有 37 个，这解决问题的比例与速度值得每位开源项目的作者学习。

同样的，大家在使用一些开源项目有问题的时候都可以提 Issue，可以通过点击右上角的 New Issue 来新建 Issue，需要添加一个标题与描述就可以了，这个操作很简单。

Pull requests

我们都知道 GitHub 的最大魅力在于人人都可参与，比如别人开源一个项目，我们每个人都可以一起参与开发，一起来完善，而这都通过 Pull requests 来完成，简称 PR。这个没法在 Retrofit 演示，下面我就以我自己在 GitHub 上的一个项目 9GAG 来给大家详细演示下怎么给一个项目发起 PR：

提前说明下，你必须确保你可以正常向 GitHub 提交代码，如果不可以的话，请看我之前的系列文章。

第一步登录你的 GitHub 账号，然后找到你想发起 PR 的项目，这里以 9GAG 为例，点击右上角的 Fork 按钮，然后该项目就出现在了你自己账号的 Repository 里。

请注意，这个项目原本是属于 GitHub 账号 stormzhang 下的，为了演示，我自己又重新注册了另一个账号叫 googdev 单纯为了演示而用。

Fork 之后，在账号 googdev 下多了一个 9GAG 的项目，截图显示如下：

可以看到 Fork 过来的项目标题底部会显示一行小字：fork from stormzhang/9GAG ，除此之外，项目代码跟原项目一模一样，对于原项目来说，相当于别人新建了一个分支而已。

第二步，把该项目 clone 到本地，然后修改的 bug 也好，想要新增的功能也好，总之把自己做的代码改动开发完，保存好。为了方便演示，我这里只在原项目的 README.md 文件添加了一行文字：Fork from stormzhang !

接着，把自己做的代码改动 push 到你自己的 GitHub 上去。

相信看过我前面教程的同学这一步应该都会，不会的可以滚回去看前面的教程了。

第三步，点击你 Fork 过来的项目主页的 Pull requests 页面，

点击 New pull request 按钮紧接着到如下页面：

这个页面自动会比较该项目与原有项目的不同之处，最顶部声明了是 stormzhang/9GAG 项目的 master 分支与你 fork 过来的 googdev/9GAG 项目 master 分支所做的比较。

然后最顶部可以方便直观的看到到底代码中做了哪些改动，你们也看到我就是加了一句 Fork from stormzhang !

同样的我写好标题和描述，然后我们点击中间的 Create pull request 按钮，至此我们就成功给该项目提交了一个 PR。

然后就等着项目原作者 review 你的代码，并且决定会不会接受你的 PR，如果接受，那么恭喜你，你已经是该项目的贡献者之一了。

Projects

这个是最新 GitHub 改版新增的一个项目，这个项目就是方便你把一些 Issues、Pull requests 进行分类，反正我觉得该功能很鸡肋，起码到目前为止基本没人用该功能，你们了解下就好。

Wiki

一般来说，我们项目的主页有 README.me 基本就够了，但是有些时候我们项目的一些用法很复杂，需要有详细的使用说明文档给开源项目的使用者，这个时候就用到了 Wiki。

使用起来也很简单，直接 New Page ，然后使用 markdown 语法即可进行编写。

Pulse

Pulse 可以理解成该项目的活跃汇总。包括近期该仓库创建了多少个 Pull Request 或 Issue，有多少人参与了这个仓库的开发等，都可以在这里一目了然。

根据这个页面，用户可以判断该项目受关注程度以及项目作者是否还在积极参与解决这些问题等。

Graphs

Graphs 是以图表的形式来展示该项目的一个整体情况。比如项目的全部贡献人，比如 commits 的围度分析，比如某天代码提交的频繁程度等。

Settings

如果一个项目是自己的，那么你会发现会多一个菜单 Settings，这里包括了你对整个项目的设置信息，比如对项目重命名，比如删除该项目，比如关闭项目的 Wiki 和 Issues 功能等，不过大部分情况下我们都不需要对这些设置做更改。感兴趣的，可以自行看下这里的设置有哪些功能。

以上就包含了一个 GitHub 项目的所有操作，相信大家看完之后对 GitHub 上一些常用的操作都熟悉了，从现在开始，请一起参与到开源社区中来吧，开源社区需要我们每个人都贡献一份力，这样开源社区才能越来越强大，也才能对更多的人有帮助！

如何发现优秀的开源项目

GitHub 其中一个最重要的作用就是发现全世界最优秀的开源项目，你没事的时候刷刷微博、知乎，人家没事的时候刷刷 GitHub ，看看最近有哪些流行的项目，久而久之，这差距就越来越大，那么如何发现优秀的开源项目呢？这篇文章我就来给大家介绍下。

关注一些活跃的大牛
GitHub 主页有一个类似微博的时间线功能，所有你关注的人的动作，比如 star、fork 了某个项目都会出现在你的时间线上，这种方式适合我这种比较懒的人，不用主动去找项目，而这种基本是我每天获取信息的一个很重要的方式。不知道怎么关注这些人？那么很简单，关注我 stormzhang ，以及我 GitHub 上关注的一些大牛，基本就差不多了。

Trending

点击下图的 Explore 菜单到“发现”页面

紧接着点击 Trending 按钮

这个 Trending 页面是干嘛的呢？直译过来就是趋势的意思，就是说这个页面你可以看到最近一些热门的开源项目，这个页面可以算是很多人主动获取一些开源项目最好的途径，可以选择「当天热门」、「一周之内热门」和「一月之内热门」来查看，并且还可以分语言类来查看，比如你想查看最近热门的 Android 项目，那么右边就可以选择 Java 语言。

这样页面推荐大家每隔几天就去看下，主动发掘一些优秀的开源项目。

除了 Trending ，还有一种最主动的获取开源项目的方式，那就是 GitHub 的 Search 功能。

举个例子，你是做 Android 的，接触 GitHub 没多久，那么第一件事就应该输入 android 关键字进行搜索，然后右上角选择按照 star 来排序，结果如下图：

如果你是学习 iOS 的，那么不妨同样的方法输入 iOS 关键字看看结果：

可以看到按照 star 数，排名靠前基本是一些比较火的项目，一定是很有用，才会这么火。值得一提的是左侧依然可以选择语言进行过滤。

而对于实际项目中用到一些库，基本上都会第一时间去 GitHub 搜索下有没有类似的库，比如项目中想采用一个网络库，那么不妨输入 android http 关键字进行搜索，因为我只想找到关于 Android 的项目，所以搜索的时候都会加上 android 关键字，按照 star 数进行排序，我们来看下结果：

可以看到 Retrofit、OkHttp、android-async-http 是最流行的网络库，只不过 android-async-http 的作者不维护了，之前很多人问我网络库用哪个比较好？哪怕你对每个网络库都不是很了解，那么单纯的按照这种方式你都该优先选择 Retrofit 或者 OkHttp，而目前绝大部分 Android 开发者确实也都是在用这两个网络库，当然还有部分在用 Volley 的，因为 google 没有选择在 GitHub 开源 volley，所以搜不到 volley 的上榜。

除此之外，GitHub 的 Search 还有一些小技巧，比如你想搜索的结果中 star 数大于1000的，那么可以这样搜索：

android http stars:>1000

当然还有其他小技巧，但是我觉得不是很重要，就不多说了。

有些人如果习惯用 Google 进行搜索，那么想搜索 GitHub 上的结果，不妨前面加 GitHub 关键字就ok了，比如我在 google 里输入 GitHub android http ，每个关键字用空格隔开，然后搜索结果如下：