Jujutsu，也就是 jj，正在成为不少开发者试验的新版本控制前端。它保留 Git 生态的互操作性，但把工作区、提交重写和变更管理做得更明确。问题是，日常协作并不只发生在本地版本控制里。只要团队还用 GitHub，Pull Request、CI 状态、review 分支和 stacked PR 仍然要处理。

今天推荐的 mrjones2014/jj-gh 就是为这段空隙准备的工具。它是一个 Rust 写的 CLI，可以通过 jj alias 变成 jj pr ... 子命令，让你在终端里创建 PR、编辑 PR、按 PR 号拉取分支、在 jj log 里显示 GitHub 元数据，并根据本地 revision graph 重新设置 stacked PR 的 base。

发布时 GitHub 搜索结果显示项目约 22 stars、2 forks，主要语言是 Rust，许可为 MIT。项目创建于 2026-05-21，最近仍在更新；仓库 changelog 里的最新版本是 jj-gh-v0.2.5，发布时间为 2026-06-11。

项目概览

属性详情
仓库mrjones2014/jj-gh
定位jj 用户的 GitHub PR 辅助 CLI
Stars约 22
Forks2
主要语言Rust
许可MIT
Latest releasejj-gh-v0.2.5

把 PR 操作放回终端

jj-gh 的核心体验不是替代 GitHub，而是减少在本地 revision 操作和网页 PR 操作之间来回切换的次数。README 推荐把它配置成 jj alias：

[aliases]
pr = ["util", "exec", "--", "jj-gh", "pr"]

配置之后，jj pr create <rev> 会从指定 revision 打开编辑器，让你写 PR 描述并通过 markdown frontmatter 设置标题、base、label、draft、auto-merge 等元数据。命令完成后，它再把这些信息提交给 GitHub。

这种做法对 jj 用户很自然。你已经用 revision id、bookmark 和 revset 描述本地历史，那么创建 PR 时继续用 <rev> 指向要提交的变更，比先手动找 branch 再切到浏览器更顺。

Stacked PR 是它的重点场景

很多 GitHub CLI 工具都能创建 PR，但 jj-gh 更强调 stacked PR。pr create 默认会根据本地 revision 图寻找最近的 ancestor bookmark；如果祖先 bookmark 已经有 open PR，它就可以把新 PR 的 base 设到正确位置。

这点对 Jujutsu 工作流很重要。jj 鼓励把变更拆成一组可重写、可重排的 revision；如果你用这种方式维护一个 stack，PR base 的正确性就会影响 reviewer 看到的 diff 范围。

jj-gh 还提供 jj pr restack。它不会改写本地 graph，而是根据你已经调整好的本地形状，去 GitHub 上更新每个 PR 的 base branch。换句话说，本地历史仍然由 jj rebase 等命令负责；jj-gh 负责把这个结构同步到 PR 层。

jj pr log 让 PR 状态进入提交图

另一个很实用的命令是 jj pr log。它类似 jj log，但会给 commit graph 注入 PR 元数据，例如 PR number、URL、CI status、merge status。

如果你正在维护一组相关改动，单看本地 graph 往往还不够。你还想知道哪一个 revision 已经开了 PR、CI 是成功还是失败、是否已经进入 auto-merge 或 merge queue 相关状态。把这些信息放进 log 输出，能减少“这个 revision 对应哪个 PR”的认知负担。

文档里也说明了它的实现方式：命令会用临时配置把 PR 相关 template alias 注入 jj log，并允许你继续把参数转发给底层的 jj log。这意味着它不是另起一套完全不同的视图，而是在 jj 原有查询能力上补充 GitHub 信息。

拉取外部 PR 时更适合开源协作

jj pr fetch <pr-num> 可以把一个 Pull Request 拉成本地 bookmark，默认命名类似 pr-1234/<branch>。它也支持跨 fork 的 PR，这对开源项目 review 很有价值。

Jujutsu 当前还不能直接 fetch refs/pull/<n>/head 这类任意 ref，所以 jj-gh 在这个操作上会要求 colocated git repo，并调用 git 完成 fetch。这个限制被 README 明确写出来，属于工具边界，而不是隐藏行为。

对实际协作来说，这个功能解决的是“我要在本地跑一遍别人的 PR”。如果你经常 review 开源项目，或者需要把同事的 PR 拉到本地试运行，jj pr fetch 比手动拼 refspec 更轻。

编辑器前置，而不是网页表单前置

pr create 和 pr edit 都走编辑器流程。命令打开一个 markdown 文件，正文是 PR body，frontmatter 则承载 title、base、labels、draft、auto_merge 等结构化字段。

这个设计有两个好处。第一，写长 PR 描述时，你可以使用自己熟悉的编辑器、补全和模板。第二，工具可以只应用你改过的元数据，避免覆盖其他机器人或 reviewer 后续添加的状态。

jj-gh 还支持 PR body template。模板可以来自 CLI 参数、repo config、.github/PULL_REQUEST_TEMPLATE.md，或者用户全局配置。更有意思的是，模板可以使用 jj template string，根据 revset 中的提交描述生成初始内容。对多 commit stack 来说，这比从空白文本框开始写更贴近本地历史。

认证配置比较务实

GitHub 操作绕不开 token。jj-gh 支持 gh_askpass、JJ_GH_TOKEN、GH_TOKEN、配置里的 gh_token，也可以尝试读取 gh auth token。README 明确建议优先使用 askpass 或 GitHub CLI 登录，而不是把明文 token 放在配置里。

这类细节看似普通，但对小工具很关键。一个 PR 辅助工具如果要求用户把长期 token 写进项目配置，就很难放心使用。jj-gh 给出的 precedence 也比较清楚：CLI 参数、环境变量、额外配置、repo config、global config、内建默认值依次合并。

如果你打算在公司仓库里使用，仍然需要仔细确认 token 权限。文档列出了不同功能会用到 Metadata、Commit Statuses、Contents、Pull requests、Issues 等权限。尤其是 labels 走 GitHub Issues API，这一点容易被忽略。

安装方式仍偏早期用户

安装方面，jj-gh 支持 cargo install jj-gh，也提供 Nix flake、overlay 和 home-manager module。它还可以生成 shell completion，包括作为 jj alias 使用时的 completion overlay。

这些选择说明项目目前主要面向已经熟悉 Rust/Nix/命令行配置的用户。它不是“下载一个 app 就能用”的工具，也不适合不了解 jj 的团队直接推广。

不过对目标用户来说，这反而是合理的边界。你需要先已经在使用 Jujutsu，并且愿意把 GitHub PR 操作纳入终端流程；在这个前提下，alias、completion、template 和 config layering 才会真正省时间。

适合什么人先试

我会优先把 jj-gh 推荐给这几类用户：

  1. 已经在个人项目或团队里使用 jj，但 PR 操作仍然依赖 GitHub 网页。
  2. 经常维护 stacked PR，希望本地 revision graph 和 GitHub PR base 更一致。
  3. 想在 jj log 里同时看到 PR number、CI status 和 merge status。
  4. 经常 review 外部 PR，需要把 GitHub PR 拉成本地 bookmark。
  5. 能接受早期 CLI 工具的配置成本，并愿意核对 GitHub token 权限。

如果你的团队仍然完全基于传统 Git branch 工作流，或者只偶尔开一个简单 PR，那么 gh pr create 可能已经足够。jj-gh 的价值主要出现在 Jujutsu 已经成为日常工作入口之后。

小结

mrjones2014/jj-gh 的价值在于把 GitHub PR 层接到 jj 的本地模型上。它不是通用 GitHub 桌面客户端，而是给 Jujutsu 用户准备的一组窄工具：从 revision 创建 PR、把 PR 信息显示到提交图、拉取外部 PR、编辑 PR 元数据，并把本地 stack 的形状同步到 GitHub。

如果你已经在用 jj，并且 stacked PR、开源 review 或终端内协作是日常工作的一部分，jj-gh 值得放进工具箱。它还很年轻，但方向很清楚：让 GitHub 协作少一点网页切换，多一点本地历史的上下文。