本地预览拉取请求
在浏览器里读一份差异，只能告诉你这段代码读起来顺不顺。它不会告诉你这个应用还能不能启动。要知道那一点，你得把这个分支跑起来——而人们恰恰卡在这里，因为来自复刻的拉取请求住在一个你从没克隆过、往往还推不进去的仓库里。
本地预览用一个大多数人一辈子都不必学的事实解决了它：托管平台会把每一个拉取请求的头部，当作一个普通的 git ref 发布在目标仓库上。那个复刻不必是能访问的，你不需要 API 令牌，也不会添加第二个远程。一次获取，代码就在你的磁盘上了。
| 托管平台 | PR 头部所在的位置 |
|---|---|
| GitHub、GitHub Enterprise、Gitea、Forgejo、Gogs | refs/pull/<n>/head |
| GitLab（云端与自托管） | refs/merge-requests/<n>/head |
| Bitbucket Cloud、Bitbucket Server | refs/pull-requests/<n>/from |
| Azure DevOps | refs/pull/<n>/merge |
Gitcito 在一次 ls-remote 里把这四种都探一遍，所以只要一个陌生的或自托管的平台遵循其中某一种约定，它就能用。
从哪里打开
- 侧边栏里的拉取请求列表——任意一条上的那个箭头按钮。这条路对每个托管平台都有效，不像详情视图那样只支持 GitHub。
- 命令面板：本地预览拉取请求。
- 在某个拉取请求的详情视图里，「在浏览器中打开」按钮的旁边。
你要给它什么
远程——这个拉取请求是冲着哪个仓库开的，通常是 origin。不是那个复刻。
拉取请求——编号，或者粘贴一个浏览器 URL。7、#7 和 https://github.com/owner/repo/pull/7 都行；GitLab、Bitbucket 和 Azure DevOps 的 URL 形状也一样。按查找，Gitcito 会在获取任何东西之前先告诉你它解析出的 ref，以及那个 ref 指向的提交。
远程分支——第二个标签页，用于根本找不到 PR ref 的情况：平台不发布它们，或者你就是想试一个分支。填上它在远程上的分支名。
应用它的两种方式
两种都不会写下提交。这是故意的——一个你走不开的预览，就不是预览。
| 方式 | 会发生什么 | 怎么撤销 |
|---|---|---|
| 一个本地分支 | 这个 ref 被获取到它自己的分支上（默认是 pr/7）并检出。你的其他分支毫发无损。 |
撤销会回到你原来所在的分支，并删掉这个预览分支。 |
| 一次未提交的合并 | 这个 ref 被以 --no-commit --no-ff 合并进当前分支，把合并后的整棵树留在暂存状态，你可以直接构建和测试。 |
撤销会中止这次合并。 |
对同一个拉取请求预览第二次会复用同一个分支，把它移到新的头部上——作者在你测试的时候推了个修复，这就很方便。当那个分支已经存在时，Gitcito 会说明并先征求同意再重置它，因为只存在于那里的提交会丢失。
它不会做的事
- 它变不出托管平台没发布的 ref。 有些自托管配置关掉了 PR ref；有些平台压根就没有过。你会得到一句清楚的「#n 没有对应的 ref」，以及远程分支那个标签页作为出路。
- 它不获取标签。 一次预览不该把别人的标签命名空间拖进你的仓库。
- 合并方式需要一个干净的工作区。 git 拒绝在未提交的工作之上做合并；先去贮藏。
- 预览不是评审。 它只是把代码放到你机器上——它不批准、不评论、也不合并任何东西。那些是托管与拉取请求的事。
- 私有复刻仍然是私有的。 PR ref 是由目标仓库提供的，所以访问权限跟着你对那个远程的凭据走——见安全。
收拾干净
预览分支就是一个普通分支：用完了就在侧边栏里删掉它，或者在预览之后直接按撤销。一次留着没提交的预览合并，可以用撤销丢掉；如果你想了想还是要它，也可以解决冲突并提交——到那一刻它就不再是预览，而变成了一次合并。