jj-gh - Jujutsu user のための GitHub PR command-line workflow

Jujutsu、つまり jj は、新しい version control frontend として試す developer が増えている tool です。Git ecosystem との interoperability を保ちながら、workspace、history rewrite、change management をより明示的に扱えます。ただし、日常の collaboration は local version control だけでは完結しません。Team が GitHub を使っている限り、Pull Request、CI status、review branch、stacked PR も扱う必要があります。

今日紹介する mrjones2014/jj-gh は、その隙間を埋めるための tool です。Rust 製の CLI で、jj alias として設定すると jj pr ... subcommand のように使えます。Terminal から PR を作成し、編集し、PR number で fetch し、jj log に GitHub metadata を表示し、local revision graph に合わせて stacked PR の base を更新できます。

公開時点の GitHub search result では、およそ 22 stars、2 forks。主な言語は Rust、license は MIT です。Project は 2026-05-21 に作成され、現在も更新されています。Repository changelog にある latest version は jj-gh-v0.2.5、公開日は 2026-06-11 です。

プロジェクト概要

項目	内容
Repository	mrjones2014/jj-gh
位置づけ	`jj` user のための GitHub PR 補助 CLI
Stars	約 22
Forks	2
主な言語	Rust
License	MIT
Latest release	jj-gh-v0.2.5

PR 操作を terminal に戻す

jj-gh の中心体験は、GitHub を置き換えることではありません。Local revision 操作と web 上の PR 操作を行き来する回数を減らすことです。README では、次のように jj alias として設定する例が示されています。

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

設定すると、jj pr create <rev> は指定した revision から editor を開きます。そこで PR description を書き、markdown frontmatter で title、base、label、draft、auto-merge などの metadata を設定します。その後、command が GitHub に PR を作成します。

この flow は jj user には自然です。すでに revision id、bookmark、revset で local history を表現しているなら、PR 作成でも <rev> で対象 change を指す方が、branch を探して browser に移動するより一貫しています。

Stacked PR が重要な利用場面

多くの GitHub CLI tool は PR を作成できますが、jj-gh は stacked PR を強く意識しています。pr create は default で local revision graph から近い ancestor bookmark を探します。Ancestor bookmark に open PR があれば、新しい PR の base をそこに合わせられます。

これは Jujutsu workflow では重要です。jj は change を rewrite 可能で並べ替え可能な revision の集合として扱いやすい tool です。その形で stack を管理している場合、PR base が正しいかどうかは reviewer が見る diff range に直結します。

jj-gh には jj pr restack もあります。これは local graph を rewrite する command ではありません。User がすでに local graph を整えたあと、その形に合わせて GitHub 上の各 PR の base branch を更新します。Local history は jj rebase などが担当し、jj-gh はその構造を PR layer に反映します。

`jj pr log` で PR 状態を commit graph に入れる

もうひとつ実用的なのが jj pr log です。これは jj log に似ていますが、commit graph に PR metadata を注入します。たとえば PR number、URL、CI status、merge status です。

関連する change の stack を扱っていると、local graph だけでは足りないことがあります。どの revision が PR になっているか、CI が成功したか失敗したか、auto-merge や merge queue に関係する状態かを知りたい場面があります。これを log output に出せると、「この revision はどの PR だっけ」と確認する負担が下がります。

Documentation によると、command は temporary config を使って PR related template alias を jj log に注入します。さらに、argument を underlying jj log に渡せます。つまり別の独自 view を作るというより、jj の query capability に GitHub information を足す design です。

外部 PR の fetch は open-source review に向いている

jj pr fetch <pr-num> は Pull Request を local bookmark として fetch できます。Default name は pr-1234/<branch> のような形です。Fork をまたぐ PR にも対応しているため、open-source project の review で便利です。

Jujutsu は現時点で refs/pull/<n>/head のような arbitrary ref を直接 fetch できないため、この operation では colocated git repo と git on PATH が必要です。README はこの制約を明記しています。隠れた動作ではなく、tool boundary として説明されています。

実際の collaboration では、「他人の PR を local で試す」ための機能です。Open-source project をよく review する人や、同僚の PR を local で動かしたい人にとって、jj pr fetch は手で refspec を組み立てるより軽い workflow になります。

Editor-first で PR を書く

pr create と pr edit は editor flow を使います。Command は markdown file を開き、body は PR body、frontmatter は title、base、labels、draft、auto_merge などの structured field を持ちます。

この design には 2 つの利点があります。ひとつは、長い PR description を普段の editor、completion、template と一緒に書けること。もうひとつは、tool が変更された metadata だけを適用でき、bot や reviewer があとから追加した状態を不用意に上書きしにくいことです。

jj-gh は PR body template もサポートします。Template は CLI argument、repo config、.github/PULL_REQUEST_TEMPLATE.md、user global config から解決できます。さらに jj template string を使い、revset 内の commit description から initial body を作れます。Multi-commit stack では、空の text area から書くより local history に沿った starting point になります。

Authentication の設計は現実的

GitHub 操作には token が必要です。jj-gh は gh_askpass、JJ_GH_TOKEN、GH_TOKEN、config 内の gh_token、さらに gh auth token の利用をサポートします。README は plain token を config に置くより、askpass や GitHub CLI login を使うことを勧めています。

このような detail は地味ですが、小さな developer tool では重要です。PR helper が long-lived token を project config に書くことを前提にすると、安心して導入しにくくなります。jj-gh の config precedence も明確です。CLI flags、environment、extra config、repo config、global config、built-in defaults の順に解決します。

Company repository で使う場合は、token permission を確認する必要があります。Documentation には Metadata、Commit Statuses、Contents、Pull requests、Issues など、機能ごとに必要な permission が整理されています。特に labels が GitHub Issues API を通る点は見落としやすいところです。

Install はまだ early user 向け

Install 方法としては cargo install jj-gh が使えます。Nix flake、overlay、home-manager module も用意されています。Shell completion も生成でき、jj alias として使う場合の completion overlay もあります。

これらを見ると、現時点の target は Rust、Nix、command-line config に慣れた user です。「app を download してすぐ使う」種類の tool ではなく、jj を知らない team にそのまま広げるものでもありません。

ただし target user にとっては、この boundary は自然です。まず Jujutsu を日常的に使っていて、GitHub PR 操作も terminal workflow に入れたい。その前提があると、alias、completion、template、config layering が時間を節約します。

先に試す価値がある人

jj-gh をまず勧めたいのは、次のような人です。

個人 project や team で jj を使っているが、PR 操作はまだ GitHub web に頼っている。
Stacked PR をよく扱い、local revision graph と GitHub PR base を揃えたい。
jj log の中で PR number、CI status、merge status も見たい。
外部 PR を review することが多く、GitHub PR を local bookmark として fetch したい。
Early-stage CLI tool の設定コストを受け入れ、GitHub token permission を確認できる。

一方で、team がまだ traditional Git branch workflow だけで動いている場合や、たまに simple PR を開くだけなら、gh pr create で十分かもしれません。jj-gh の価値は、Jujutsu がすでに日常の入口になっているときに強く出ます。

まとめ

mrjones2014/jj-gh の価値は、GitHub PR layer を jj の local model に接続することです。General-purpose な GitHub desktop client ではなく、Jujutsu user のための narrow tool set です。Revision から PR を作り、PR information を commit graph に表示し、外部 PR を fetch し、PR metadata を編集し、local stack の形を GitHub に反映します。

すでに jj を使っていて、stacked PR、open-source review、terminal-first collaboration が日常にあるなら、jj-gh は tool box に入れる価値があります。まだ若い project ですが、方向性ははっきりしています。GitHub collaboration の browser switching を減らし、local history の context を保ったまま作業するための tool です。