传统认证方式到底哪里难受？

说实话，在接触 gh 之前，我一直觉得 GitHub 的认证这块挺烦的。不是说它不能用，而是用起来总有点别扭。

先说用 HTTPS 加令牌这条路。GitHub 要求你去网页端生成一串很长的字符串，复制下来，然后在命令行里粘贴进去。这本身倒没什么，麻烦的是如果你在 Linux 下没有专门配凭据管理器，这串 token 它不帮你记住。下次推代码，还得重来一遍。久而久之就觉得很累，因为这种重复性的体力劳动跟写代码本身没有任何关系。

SSH 密钥的方案是很多老手的首选，也确实更安全、更稳定。但配起来步骤不少：先生成密钥对，再把公钥复制到 GitHub 网页里，再去编辑本地的 ssh 配置文件，然后测试一下连通性。单台机器还好，如果你经常换电脑或者同时用好几台设备，每台都要重新走一遍这套流程，说不烦是假的。而且 SSH 说到底只解决了代码拉取推送的问题，GitHub 平台上其他的东西——议题、合并请求、代码搜索——它都管不着。

gh 做了什么

gh 是 GitHub 官方出的命令行工具。它最核心的功能不是让你在终端里看议题（虽然这个也挺好用的），而是它接管了 Git 的认证这一块。

登录的过程很简单。你跑 gh auth login，终端里会给你一个短码，然后自动打开浏览器，你在网页上点一下授权，就结束了。不需要你手动生成任何 token，不需要记住任何字符串。

登录完之后，gh 会把自己注册成 Git 的凭据助手。具体是修改了 Git 的底层配置，让 credential.helper 指向 gh 自己。效果就是：以后你跑任何 git push 或者 git clone，Git 碰到 GitHub 的地址，会自动去问 gh 要权限，整个过程你完全不用管。

装起来也不麻烦

我自己用 mise 装的，一行命令：

mise use --global gh@latest

mise 是个环境管理工具，可以统一管理各种语言运行时和命令行工具的版本，我用了挺长时间了，挺顺手的。当然你也可以直接用系统包管理器，apt install gh 或者 brew install gh 都行，效果是一样的。

装完之后跑登录：

gh auth login

按照提示选 GitHub.com，然后选 HTTPS，走浏览器授权那条路。授权完就好了，之后的 git push、git pull 全部自动走认证，不会再问你要密码或者 token。

生成token时注意至少要勾选这三个权限：repo、read:org、workflow，少了会有权限报错。

还有一个用途，跟 AI 有关

这部分可能有些人没想到过。

现在很多人在用 AI 辅助开发，经常会遇到"我想让 AI 去参考一下某个开源项目的实现"这种需求。以前的做法是让 AI 把整个仓库 clone 下来，几百兆的东西全下到本地，既慢又乱，AI 的上下文也容易被一堆不相关的文件撑满。

如果你装了 gh 并且登录了，Cursor 或者 Claude 这类工具可以通过 GitHub 的 MCP 插件直接调用 GitHub 的接口，在云端搜索代码、读取特定文件、查看议题讨论，完全不需要把整个仓库拉下来。你跟 AI 说"帮我看看 React 仓库里 useEffect 相关的最近讨论"，它直接去查，查完告诉你，不会在你硬盘上留下任何东西。

这个功能能不能用，前提就是本地有有效的 GitHub 认证。gh 登录之后，这个条件自然就满足了。

总结一下

我现在换电脑之后第一件事就是跑 gh auth login，比以前去网页上找 Developer Settings 生成 token、或者重新配 SSH 密钥省事多了。如果你还没试过，值得花五分钟体验一下。