![a88b36f220f7213e3de301679e88aaed.png](https://i-blog.csdnimg.cn/blog_migrate/39ff12dc4bb83fd675f83898e88d352a.jpeg)
GitHub最近发布了GitHub CLI,这是一个第一方命令行工具,可以通过命令行与GitHub对接。
通过GitHub CLI,开发者可以查看GitHub的问题(issues)和拉取请求(pull request)的状态,搜索特定的问题或PR,创建/分叉一个Repo,或者直接在命令行创建新的问题和拉取请求。
在这篇文章中,我们将介绍一些常见的日常开发者工作流程。我们将重点讨论如何使用 GitHub CLI 管理问题和拉取请求。
什么是GitHub CLI?
![c08b8c04299ee0f622cbe7557a1c788c.gif](https://i-blog.csdnimg.cn/blog_migrate/27cbddd8ac34b6ef636630d16e123995.gif)
GitHub CLI官方网站:https://cli.github.com/
所以,我们先来简单介绍一下GitHub CLI。如果你已经很熟悉了,那就提前跳到下一节。
最好将GitHub CLI描述为“从命令行获取GitHub”。
目前,GitHub CLI的版本为v0.6.3,主要由三个GitHub神器组成。
- Issues
- Pull Requests
- Repositories
使用GitHub CLI,开发人员可以针对不同的工具执行以下命令:
所以,我们先来简单介绍一下GitHub CLI。如果你已经很熟悉了,那就提前跳到下一节。
最好将GitHub CLI描述为“从命令行获取GitHub”。
目前,GitHub CLI的版本为v0.6.3,主要由三个GitHub神器组成。
- Issues
- Pull Requests
- Repositories
使用GitHub CLI,开发人员可以针对不同的工具执行以下命令:
- create
- list
- status
- view
- checkout (pull requests only)
- clone (repo only)
- fork (repo only)
如前所述,在本文中,我们将只关注与Issues和Pull Requests相关的命令。
如何安装GitHub CLI?
要将GitHub CLI安装在开发机器上,请查看GitHub上的安装指南。这里以Mac为例,有两种安装方式
- brew安装:brew install github/gh/gh
- 直接下载安装包
GitHub CLI可在MacOS,Windows和各种Linux发行版中使用,因此在计算机上启动并运行该工具应该没有问题。
![431443fb95e22abd5cf8f1dc5bb2c6e0.png](https://i-blog.csdnimg.cn/blog_migrate/ccc6fba755bdc190810dc88a6411c9e8.jpeg)
使用GitHub CLI管理GitHub Issues
如果你在开发流程中经常使用GitHub Issues,那么GitHub CLI可能会为你提供一些有用的命令。让我们看一下典型工作日的样子,并重点介绍一些使用GitHub CLI处理GitHub上的Issues的示例。
/ 列出GitHub CLI的Issues /
假设我们今天只是坐在电脑前,想把我们项目的GitHub Issues列出来。
gh issue list
如果我们想列出所有问题,可以使用“state”标志
gh issue list --state "all"gh issue list -s "all"gh issue list --state "all"gh issue list -s "all"
现在,也许我们已经意识到有太多问题需要解决,所以我们决定只列出你当前分配的问题。
gh issue list --assignee "n8ebel"
或者,你可以使用简写形式
gh issue list -a "n8ebel"
/ 使用GitHub CLI检查Issue状态 /
接下来,我们要检查昨天创建的几个Issue的状态。也许我们不记得它们的确切数字,但是由于创建了它们,我们可以使用status命令在终端上列出它们:
gh issue status
这将向我们提供分配给我们的Issue列表,提到我们或由我们打开的Issue。
在检查了这些问题之后,我们仍然找不到所需的问题,因此我们可能要检查它是否已关闭。
gh issue list --state "closed"gh issue list -s "closed"
这下好了! 我们的问题已经结束了,所以现在我们可以开始寻找下一个任务了。 我们可以开始寻找新的任务,把不同的标签筛选出来,列出不同的标签来寻找新的任务。
要列出所有未解决的bug,我们可以按GitHub 仓库中定义的“bug”标签进行过滤
gh issue list --label "bug"gh issue list -l "bug"
如果你不确定有哪些标签,你可以先把所有的未完成的问题都列举出来,再进行检查。
gh issue list
现在,我们可以看到还有一个我们可以搜索的 enhancement 标签
gh issue list -l "enhancement"
![76d2a556e97f7f026cbbb953c76aeb03.png](https://i-blog.csdnimg.cn/blog_migrate/a699ef5a405c6d62ea588ad6d347823c.jpeg)
/ 查看GitHub CLI的 Issues /
找到要解决的Issue后,我们可能希望将该Issue分配给自己。目前,我们无法直接从命令行执行此操作,但可以使用“view”命令从命令行快速打开问题。
gh issue view "15"
这将在浏览器中打开Issue,然后你可以将其分配给自己。
在将任何问题分配给自己之后,你可以从命令行中列出分配给你的打开的Bug,从而重复检查你的任务。
gh issue list -a "n8bel" -l "bug"
/ 使用GitHub CLI创建Issue /
现在,我们只需探索最后一个命令。
在我们处理分配的Issue时,想象一下我们发现了另一个需要报告的bug。
我们可以使用 gh issue create 命令直接从命令行创建一个新的GitHub Issue。
gh issue create
使用此命令将启动一个交互式终端工作流,以选择任何可用的GitHub Issue模板,然后填写标题和Issue描述。最后,你可以选择提交Issue、在浏览器中打开Issue或取消Issue。
如果你想简化一些事情,可以使用其他标志通过命令指定问题
gh issue create -t "Sample Issue Title" -b "Sample issue description"
如果你仍然喜欢从网络上创建Issue,你可以使用以下命令打开浏览器窗口,直接跳转到你的repo中的Issue创建工作流程中去
gh issue create --web
/ 有用的GitHub CLI别名 /
通过这些不同的命令和标志变化,我们有相当多的选项来创建、列出和查看我们的GitHub Issue。
通过为它们创建一些命令行别名,我们可以使这些命令更易于使用。
例如,列出所有bug时,不要使用此完整命令
gh issue list --label "bug"
我们可以这样创建一个别名
alias listbugs='gh issue list --label "bug"'
这样,当我们要列出所有Bug时,我们只需键入:
listbugs
另一个示例是使用以下别名列出分配给你的所有Bug。
alias listmybugs='gh issue list -a "" -l "bug"'
使用此别名后,我们可以像这样搜索分配给你的所有Bug:
listmybugs
![458edde58188ec31479148fb6b42e491.png](https://i-blog.csdnimg.cn/blog_migrate/c4ab25e7832f8ab295b9a0889e3c943f.jpeg)
使用GitHub CLI管理 Pull Request
现在,让我们来探讨一下使用GitHub CLI来管理Pull Request。再次,让我们通过一个想象中的工作日,来看看这个工具能在哪些方面帮助我们。
/ 列出Pull Request /
再次,我们坐在电脑旁度过一天,我们想要列出项目的未完成Pull Request。
gh pr list
如果我们要列出所有打开和关闭的Pull Request,则可以使用“state”标志
gh pr list --state "all"gh pr list -s "all"
现在,也许我们已经意识到要解决的PR太多,所以我们决定只想列出你当前分配的问题。
gh pr list --assignee "n8ebel"
或者,你可以使用简写形式
gh pr list -a "n8ebel"
/ 检查Pull Request的状态 /
接下来,我们要检查昨天创建的几个PR的状态。也许我们不记得它们的确切数字,但是由于创建了它们,我们可以使用status命令在终端上列出它们
gh pr status
这将为我们提供分配给我们、提及我们或由我们打开的PR的列表。
在检查完这些PR之后,我们仍然找不到所需的Pull Request,因此我们可能要检查它是否已关闭。
gh pr list --state "closed"gh pr list -s "closed"
那很棒!我们的PR已关闭,因此现在我们可以找到下一个任务。我们可以通过列出由不同标签过滤的Pull Request来开始寻找新任务。
要列出所有打开的漏洞修复PR,我们可以按GitHub 仓库中定义的“bug”标签进行过滤
gh pr list --label "bug"gh pr list -l "bug"
如果你不确定哪些标签可用于未解决的问题,可以先通过再次列出所有未解决的PR进行检查
gh pr list
现在,我们看到还有一个可以搜索的 enhancement 标签
gh pr list -l "enhancement"
/ 查看Pull Request /
找到要审查的PR后,我们可能希望将该PR分配给我们自己。目前,我们无法直接从命令行执行此操作,但是我们可以使用view命令从命令行快速打开PR。
gh pr view "14"
这将在浏览器中打开Pull Request,然后你可以在其中将其分配给自己,进行查看等。
你可以通过列出分配给你的PR,从命令行中重复检查你分配的Pull Request。
gh pr list -a "n8bel" -l "bug"
/ 创建Pull Request /
在处理分配的问题时,有时会希望根据本地更改创建一个新的Pull Request。我们可以使用 gh pr create 命令直接从命令行创建一个新的Pull Request。
gh pr create
使用此命令将启动一个交互式终端工作流,填写标题和问题描述。最后,你最终可以选择提交PR,在浏览器中打开PR或取消它。
如果你想简化一下内容,可以使用带有其他标志的命令来具体说明PR信息
gh pr create -t "Sample Issue Title" -b "Sample issue description"
如果你仍然希望从网络上创建PR,则可以使用以下命令打开浏览器窗口,然后直接跳转进入PR创建工作流程
gh pr create --web
在某个时候,我们将要在本地测试PR。这一般需要查找PR,检查它所在的分支,然后在本地检查它。
使用GitHub CLI,我们可以使用pr checkout命令简化此过程
gh pr checkout "14"
这将检出与PR 14相关的分支,因此你准备开始测试。因此,有了这些各种命令和标志的变化,我们有很多创建,列出和查看GitHub pull请求的选项。
通过为它们创建一些命令行别名,我们可以使这些命令更易于使用。
例如,列出所有PR时,不要使用此完整命令
gh pr list --label "bug"
我们可以这样创建一个别名
alias listprs='gh pr list --label "bug"'
这样,当我们要列出所有与bug相关的PR时,我们只需键入
listprs
另一个示例是使用以下别名列出分配给你的所有PR
alias listmyprs='gh pr list -a ""'
使用此别名后,我们可以像这样搜索分配给你的所有PR
listmyprs
提示:
当你运行第一个GitHub CLI命令时,工具会提示你在浏览器中使用GitHub进行身份验证。一旦你输入了你的凭证,一个新的访问令牌就会被添加到你的仓库中,并用于从GitHub CLI验证。
如果对你有所启发和帮助,可以点个关注、收藏、转发,也可以留言讨论,这是对作者的最大鼓励。
私信回复:大礼包,送某网精品视频课程网盘资料,准能为你节省不少钱!