Jujutsu（ジュジュツ、コマンド名は jj）は、Gitのリポジトリをそのまま読み書きできるバージョン管理システムです。アニメ「呪術廻戦（Jujutsu Kaisen）」とは関係なく、由来は柔術です。作業中のファイルが常に1つのコミットとして記録されるため git add もstashも要らず、手元の操作は jj undo で戻せます。2026年10月時点の最新版は0.46.0（10月7日公開）で、1.0前のため毎月のリリースで破壊的変更が入ることがあります。この記事では0.46.0を実際に動かし、Windows・Mac・Linuxのインストール、既存のGitリポジトリで変更を記録してGitHubへpushするまで、履歴の直し方、VS Code拡張とGUI、古い解説が動かない理由を確認した結果をまとめます。
まとめ：Jujutsu（jj）の要点（v0.46.0時点）
- 何者か：Martin von Zweigbergk氏が2019年に趣味で始め、現在はGoogleで本人の専任プロジェクトになっているGit互換VCS。Googleの公式サポート製品ではない。ライセンスはApache-2.0。
- インストール：Windowsは
winget install jj-vcs.jj、macOSはbrew install jj、Arch Linuxはpacman -S jujutsu。0.46.0から実行時にGit 2.42.0以上が必要で、Ubuntu 22.04とDebian 12の標準のGitでは足りない。 - Gitとの違い：作業コピー自体がコミット（
@）で、ステージングが無い。ブランチに当たるブックマークは自動で進まない。コンフリクトがあってもrebaseは止まらない。 - 始め方：既存のGitリポジトリで
jj git initを打つだけ。.gitと同居する「colocate」が既定で、Gitコマンドも並行して使える。やめるときは.jjを消せば戻る。 - VS Code：MIT ライセンスの「Jujutsu Kaizen」（
jjk.jjk）か、プロプライエタリで個人は無料の「VisualJJ」。マーケットプレイスで「jujutsu」と検索すると呪術廻戦のテーマ拡張が混ざるので拡張IDで探す。 - 注意：
jj git push --allow-newは0.42で削除、jj rebase -dは0.36で-oに改名。submodule・Git LFS・Gitフックは非対応。
Jujutsu（jj）の開発元と安定度
公式リポジトリは github.com/jj-vcs/jj です（2024年に個人アカウントの martinvonz/jj から移転）。READMEの「Mandatory Google Disclaimer」では、作者が2019年末に趣味で始め、現在はGoogleで本人の専任プロジェクトになっており、複数のGoogle社員が開発に加わっていると説明しています。同じ箇所に「Googleのサポート対象製品ではない」とも明記されており、サポートはコミュニティが担います。
READMEは jj を「実験的なバージョン管理システム」と位置付け、1.0.0までにワークフローやディスク上の形式の後方互換を破る変更が入ると予告しています（Git互換の部分は安定しており、コア開発者は jj で jj 自体を開発しています）。リリースはほぼ毎月第1水曜日前後で、GitHubのリリース一覧では2026年に0.37.0（1月8日）から0.46.0（10月7日）まで毎月1本出ています（9月は0.45.0と同日の修正版0.45.1）。
Jujutsuのインストール手順：OS別のコマンドと初期設定
公式の手順書（Installation and setup）に載っている方法を中心に挙げます。どの方法で入れても、実行時にGit 2.42.0以上が要ります。0.46.0の CHANGELOG で2.41.0から引き上げられました（jj workspace add が git worktree add --orphan を使うため）。cargoでソースからビルドする場合はRust 1.97.1以上が必要です。
Windows：wingetかscoop
winget install jj-vcs.jj
# または
scoop install main/jj2026年10月24日時点で、wingetの jj-vcs.jj とScoop Mainの jj はどちらも0.46.0を収録しています。Gitが古いと動かないので、先に git --version で2.42以上かを見ておきます。Windows版Gitの更新手順はGit for Windowsの最新版は2.56.0｜ダウンロード・インストール手順と更新方法にまとめています。WSL上で使う場合はWSL側でLinuxの手順により別途入れ、設定ファイルもWindows側とは別になります。
Windowsで jj git fetch や jj git push が無言で止まる場合、ssh の鍵のパスフレーズ入力などで固まる不具合（issue #6745）の可能性があり、0.46.0で直っています。
macOS：Homebrew
brew install jj
jj --versionHomebrewの jj formulaは2026年10月24日時点で0.46.0です（別名 jujutsu）。MacPortsなら sudo port install jujutsu です。手元のXcode Command Line ToolsのGitは2.50.1（Apple Git-155）で、要件を満たしていました。
Linux：pacman・cargo-binstall・cargo
# Arch Linux
sudo pacman -S jujutsu
# ビルド済みバイナリを ~/.cargo/bin に置く（cargo-binstall導入済みの場合）
cargo binstall --strategies crate-meta-data jj-cli
# ソースからビルド（Rust 1.97.1以上。Ubuntu等は先に build-essential が必要）
cargo install --locked --bin jj jj-cliFedoraは公式手順に非公式のCOPRリポジトリ（aldantanneo/jj-vcs）が載っています。Ubuntu・Debianの公式リポジトリ向けの手順は無いため、cargoを使わないならGitHubリリースのビルド済みバイナリ（jj-v0.46.0-x86_64-unknown-linux-musl.tar.gz 等）を展開してPATHに置きます。
見落としやすいのがGitの版です。標準パッケージのGitは、Ubuntu 22.04が2.34.1、Debian 12が2.39.5で、どちらも0.46.0の要件（2.42.0以上）を満たしません。Ubuntu 24.04（2.43.0）とDebian 13（2.47.3）なら標準のままで動きます。
初期設定：名前とメールアドレス
コミットの作成者情報はGitの設定を読みません。最初に次の2行を実行します。
jj config set --user user.name "Taro Yamada"
jj config set --user user.email "[email protected]"
jj config path --user # 書き込まれたファイルの場所を確認0.45.0から、ユーザー設定ファイルが複数あるときの --user の書き込み先が変わりました。以前は対話的に選ばせていましたが、現在は最初に読み込まれるファイル（旧来の ~/.jjconfig.toml があればそれ、無ければ ~/.config/jj/config.toml または conf.d/ の先頭ファイル）へ黙って書き込みます。書き込み先を指定したいときは、--user の代わりに --file <PATH> を指定します。
Gitとの違い：作業コピーがコミットになる操作モデル
jj はGitのオブジェクト形式でデータを保存するので、リモートやCIから見れば普通のGitリポジトリです。チームの他のメンバーはGitのままで構いません。変わるのは手元の操作モデルで、Gitに慣れた人がつまずくのはほぼ次の3点です。
ステージングが無く、作業コピーそのものがコミット
jj では作業中のファイル群が常に @（working-copy commit）というコミットになっています。jj コマンドを実行するたびにファイルの状態が自動でスナップショットされ、@ に取り込まれます。そのため git add に当たる操作が無く、stashも要りません。別の作業に移りたければ jj new で新しい空のコミットを作るだけで、それまでの変更は親コミットに残ります。逆に、コミットしたくないファイルは .gitignore に書いておかないと自動で取り込まれます。
change IDとcommit IDの2つのID
jj log の各行には2つのIDが出ます。先頭の英字（例 xxmknrqv）がchange IDで、コミットを書き換えても変わりません。後ろの16進（例 3995efba）がGitのcommit IDで、書き換えるたびに変わります。0.46.0で jj describe によりメッセージを付けると、change IDはそのままでcommit IDだけが 0a4ee739 から 3995efba に変わりました。ただし jj squash で中身を全部移して空になった移動元のコミットは破棄され、そのchange IDは使えなくなります。
ブックマークとGitブランチの更新タイミングの違い
Gitのブランチに当たるものは、0.22で「bookmark」に改名されました。改名の理由は、Gitのブランチと挙動が違うため、とCHANGELOGに書かれています。一番の違いは、新しいコミットを作ってもブックマークが自動では付いてこない点です。pushする前に jj bookmark set <名前> -r @- のように位置を合わせる必要があります。ブックマークが無くても作業はでき、名前の無い変更をいくつも並行して持てます。ブランチの基本はブランチとは？バージョン管理で開発を分岐させる仕組みを参照してください。
GitとJujutsuのコマンド対応表
| やりたいこと | Git | jj（0.46.0） |
|---|---|---|
| 既存リポジトリで使い始める | – | jj git init |
| クローン | git clone URL |
jj git clone URL |
| 状態を見る | git status |
jj st |
| メッセージを付けて確定 | git commit -a -m |
jj commit -m |
| 直前のコミットに追加 | git commit --amend |
jj squash |
| メッセージだけ直す | git commit --amend -m |
jj describe -m |
| 作業を一時退避 | git stash |
jj new @- |
| 付け替え | git rebase |
jj rebase -o |
| cherry-pick | git cherry-pick |
jj duplicate -o |
| fixup の自動振り分け | git commit --fixup＋rebase -i |
jj absorb |
| 変更を捨てる | git reset --hard |
jj abandon |
| 取得・送信 | git fetch ／ git push |
jj git fetch ／ jj git push |
| 操作の取り消し | git reflog＋reset |
jj undo |
Gitコマンド側の詳しい意味はGitコマンド一覧にまとめています。
jjの基本的な使い方：既存リポジトリで変更を記録してpushするまで
既存のGitリポジトリへの導入
cd my-project # 既に .git があるリポジトリ
jj git init # .jj が作られ、.git と同居する
jj log0.34以降は同居（colocate）が既定のため、昔の解説にある --colocate は付けても付けなくても同じです。同居状態では git log や git diff もそのまま使えます。ただし git status は jj の操作後に「Not currently on any branch.」（detached HEAD）と表示します。jj がHEADを @ の親に置くためで、故障ではありません。リモートに main がある場合、初回は「jj bookmark track main@origin を実行すると今後のfetchでローカル側も更新される」というヒントが出るので、従っておきます。新規にクローンするなら jj git clone <URL> を使います。
jj log が全履歴を出さないのも仕様です。既定の表示範囲は present(@) | ancestors(immutable_heads().., 2) | trunk() で、今の作業コミット（@）、書き換え可能な（不変扱いでない）コミットとその近くの祖先、trunkだけを出します。全部見たいときは jj log -r :: です。
変更の記録：describe・new・commit
echo "b" > b.txt
jj st # A b.txt が @ に取り込まれている
jj describe -m "add b" # @ にメッセージを付ける
jj new # 次の作業用に空のコミットを作る
# 上の2行は jj commit -m "add b" 1回と同じ結果になるjj new -m "add b" のように先にメッセージを書いてから編集しても構いません。旧来の解説に出てくる jj amend と jj init は現行版にはありません。
過去のコミットを直す：edit・squash・split・absorb
Gitでは rebase -i で行う履歴の手直しを、jj は目的別のコマンドで行います。どれも書き換えたコミットの子孫を自動で付け替えるため、途中で止まって続きを指示する必要がありません。
jj squash # @ の変更を親（@-）へ移す
jj squash --into <change ID> # @ の変更を任意の祖先へ移す
jj split -r <change ID> b.txt # 指定したファイルだけを別コミットに分ける
jj absorb # @ の変更を、その行を最後に変えた祖先へ振り分ける
jj edit <change ID> # 過去のコミットを直接作業コピーにする0.46.0で試した結果は次のとおりです。「add a and b」「add c」の2コミットの上で、a.txt の2行目と c.txt を同時に直して jj absorb を打つと、「Absorbed changes into 2 revisions」と表示され、a.txt の修正は「add a and b」へ、c.txt の修正は「add c」へ、それぞれ自動で入りました。どの祖先に入れるか一意に決まらない変更は @ に残ります。
jj split -r <change ID> b.txt では、指定した b.txt 側が元のchange IDを引き継ぎ、残りが新しいchange IDのコミットになりました。0.46.0から jj split は2つのコミットの説明を1回のエディタでまとめて編集する形に変わっています。jj edit は過去のコミットを直接書き換えるため、意図しない変更まで混ざりやすい操作です。jj new <change ID> で上に作業用コミットを作り、終わったら jj squash で戻すほうが、混ざった変更を切り分けやすく安全です。
GitHubへのpush：ブックマークの作り方で3通り
jj git remote add origin [email protected]:you/repo.git # origin が未登録の場合だけ実行
# 1) 名前を付けて push（-b を付けると追跡も自動で始まる）
jj bookmark create feature-a -r @-
jj git push -b feature-a
# 2) 名前を考えずに push（push-<change ID> という名前が自動で付く）
jj git push -c @-
# 3) 引数なしは、revsets.git-push の範囲にある追跡中のブックマークを push
jj git push0.46.0では、引数なしの jj git push が送る範囲を設定 revsets.git-push で変えられるようになりました。既定値は remote_bookmarks(remote=exact:remote)..@ で、リモートにある位置から @ までの範囲です。送るものが無いときは「No bookmarks/tags found in revsets.git-push」と警告して終わります。
履歴を書き換えたあとのpushに --force は要りません。jj は最後にfetchしたリモートの状態と一致するときだけ上書きするので、動作は git push --force-with-lease 相当です。Git側での同じ操作はgit rebaseとは？使い方・mergeとの違いで解説しています。
pushが拒否される3つの条件
0.46.0で手元のリモートに対して試すと、次の3つの場合にpushが止まりました。
| 状況 | 表示 | 終了コード | 対処 |
|---|---|---|---|
新しいブックマークを -b なしでpush |
Refusing to create new remote bookmark | 0 | -b を付ける |
| 説明の無いコミットを含む | Won’t push commit … since it has no description | 1 | jj describe |
| コンフリクトを含む | Won’t push commit … since it has conflicts | 1 | 解消してから |
1つ目だけは終了コードが0なので、スクリプトやCIでは失敗に気付けません。以前はここで --allow-new を付けましたが、このフラグは0.36で非推奨、0.42で削除され、0.46.0で付けると「unexpected argument」エラーになります。毎回の追跡を省きたいなら、設定に [remotes.origin] と auto-track-bookmarks = "*" を書きます。2つ目は、説明を付け忘れた空のコミットが間に挟まっているときにも起きます。2つ目と3つ目は --allow-empty-description・--allow-conflicts を付ければ送れますが、Gitで受け取る側が困るので通常は使いません。
コンフリクトの扱い：rebaseが途中で止まらない仕組み
Gitのrebaseはコンフリクトに当たるとその場で止まり、解消するか --abort するまで次に進めません。jj はコンフリクトをコミットの中身として記録し、rebase自体は最後まで完了させます。同じファイルの同じ行を別々に変えた2つのコミットで試すと、0.46.0では次のように表示されました。
$ jj rebase -s uuwvkplt -o ltnvruxs
Rebased 1 commits to destination.
New conflicts appeared in 1 commits:
uuwvkplt 9d67dcc9 (conflict) left
Hint: To resolve the conflicts, start by creating a commit on top of
the conflicted commit:
jj new uuwvkplt
Then use `jj resolve`, or edit the conflict markers in the file directly.
Once the conflicts are resolved, you can inspect the result with `jj diff`.
Then run `jj squash` to move the resolution into the conflicted commit.jj log ではそのコミットに × と (conflict) が付き、ファイルには次の形のマーカーが書かれます。Gitの <<<<<<< と違い、片側を「差分」として示すので、どちらの変更を残すか判断しやすくなっています。
<<<<<<< conflict 1 of 1
+++++++ ltnvruxs 2e8a0b45 "right" (rebase destination)
right
%%%%%%% diff from: uxstllpr 356a2073 "base" (parents of rebased revision)
\\\\\\\ to: uuwvkplt 0493e548 "left" (rebased revision)
-line1
+left
>>>>>>> conflict 1 of 1 ends解消の手順はヒントのとおりで、jj new <衝突したコミット> で上に作業用コミットを作り、ファイルを直すか jj resolve でマージツールを開き、jj squash で解消結果を衝突したコミットへ戻します。解消するまで他の作業を続けても構いません。未解消のコミットは jj log -r 'conflicts()' で一覧できます。コンフリクト自体の仕組みはコンフリクトとは？Gitで変更が衝突する仕組みと解消手順で説明しています。
コンフリクトは標準のGitの形式では表せないため、jj はGitのコミット内に .jjconflict-base-* などの内部用ディレクトリとして保存します（公式のGit互換性資料による）。jj から操作する限り見えませんが、git switch で直接取り出すとこのディレクトリが作業コピーに現れます。「rebaseが常に成功する」は「解消しなくてよい」という意味ではなく、前の章のとおり通常のpushは拒否されます。
操作ログとjj undo：連続取り消しとワークスペースの制限
jj はリポジトリへの操作を1回ずつ操作ログ（operation log）に記録します。jj op log で一覧でき、各行に実行したコマンドそのもの（例 args: jj git push -c @-）が残ります。
jj undo # 直前の操作を取り消す（続けて打つとさらに1つ前へ）
jj redo # 取り消しをやり直す
jj op log --limit 5 # 操作ログを見る
jj op restore <操作ID> # 任意の時点のリポジトリ状態へ戻す0.33.0で jj undo は「連続」型になり、打つたびに1つずつさかのぼります。戻しすぎたら jj redo で進めます。古い記事の「undoは1回しか効かない」という説明は現行版には当てはまりません。操作ログはGitのreflogと違ってブックマークやリモート追跡の状態も含むため、ブックマークの付け間違いもまとめて戻せます。
リモートに送った内容は戻せません。push直後に jj undo を打つと「Undoing a push operation often leads to conflicted bookmarks.」と警告され、jj redo を促されました。
0.46.0からは、別のワークスペースで実行された操作を jj undo で取り消そうとすると「Refusing to undo operation … because it was performed in workspace proj-ws2」と拒否されます。並行して作業している別のワークスペースの変更を誤って戻さないための変更で、意図して戻すときは --allow-cross-workspace を付けるか、jj op revert で特定の操作だけを打ち消します。
jj workspaceで並行作業：0.46からGit worktreeとして作成
1つのリポジトリから作業コピーを複数作る機能が jj workspace です。Gitの git worktree に当たり、複数のAIコーディングエージェントに別々の変更を同時に進めさせる用途に向きます。0.46.0からは、同居（colocate）リポジトリで jj workspace add すると対応するGit worktreeも自動で作られます。
jj workspace add ../proj-ws2 # 作業コピーを追加（Git worktreeも作られる）
git worktree list # Git側からも2つ見える
jj workspace list
jj workspace remove proj-ws2 # 0.46.0の新コマンド。ディレクトリごと消す実行すると「Created Git worktree for the new workspace.」と表示され、git worktree list に元のディレクトリと proj-ws2 の2行が並びました。追加した側にも .git があるため、Gitしか知らないエディタやツールも追加した作業コピーをGitリポジトリとして扱えます。0.45以前は、同居になるのは最初の作業コピーだけでした。Git worktreeを作りたくない場合は --no-colocate を付けます。
後片付けは0.46.0で追加された jj workspace remove で、作業コピーの状態をコミットに記録してからGit worktreeとディレクトリを削除しました。jj workspace forget は作業ディレクトリと作業ファイルを残して追跡をやめます。ただし0.46.0の同居ワークスペースでは、対応するGit worktreeの登録と .git ファイルも取り除きます。
なお、公式のGit互換性一覧は今も「git-worktree: No」です。これは、Gitで作った既存のworktreeの中で jj を使う形を指しています。jj の作業コピーを増やすときは git worktree add ではなく jj workspace add から作るのが前提です。Git側の仕組みはGit Worktree（ワークツリー）とは、エージェントを並列で動かす道具の例はherdrとは？AIコーディングエージェントを並列で動かす使い方で扱っています。
古い解説が動かない理由：版ごとの破壊的変更
jj の日本語解説は2024〜2026年前半に書かれたものが多く、そのまま打つとエラーになったり、意味の無いフラグを付けたりすることになります。CHANGELOGから、入門者が踏みやすい変更だけを抜き出しました。
| 版（公開日） | 変更 | 古い記事の書き方 |
|---|---|---|
| 0.22（2024-10） | branch を bookmark に改名 | jj branch create |
| 0.33（2025-09） | undo が連続型に・redo 追加 | undo は1回だけ |
| 0.34（2025-10） | colocate が既定に | jj git init --colocate |
| 0.36（2025-12） | rebase の -d を -o に改名 |
jj rebase -d |
| 0.36（2025-12） | --allow-new 非推奨 |
jj git push --allow-new |
| 0.42（2026-06） | --allow-new を削除 |
同上（エラーになる） |
| 0.45（2026-09） | config --user の書き込み先 |
対話で選ぶ前提 |
| 0.46（2026-10） | Git 2.42.0以上が必須 | Git 2.41で動く |
| 0.46（2026-10） | 他ワークスペースの操作は undo 不可 | どこからでも undo |
-d は旧名として当面は残されており、CHANGELOGは「異例に長い非推奨期間」を置くと書いています。一方 --allow-new は既に削除済みです。調べ物で見つけたコマンドが動かないときは、まず記事の日付と jj --version を突き合わせ、公式ドキュメントの docs.jj-vcs.dev/latest で確認するのが確実です。STORES Product Blog「Gitの代わりにJujutsuを使い始めて1ヶ月」でも、生成AIに聞いたrebaseの -r と -s の説明が誤っていて1時間ほど失ったと報告されています。
Jujutsuを採用すべきでない場面：submodule・LFS・フック
公式ドキュメントのGit互換性一覧で「No」とされている機能を日常的に使うリポジトリでは、jj を主に使う運用は勧めません。
- Gitフック：非対応（issue #405）。pre-commitでlinterやgitleaksのような秘密情報の検知を走らせている場合、jj からのコミットではそれが動きません。CI側で同じ検査を必ず通す構成になっていないなら導入を見送るべきです。
- Git LFS：非対応（issue #80）。LFSで大きな画像やモデルを管理しているリポジトリでは、LFSの取得・更新をGitで行う運用が残ります。
- submodule：作業コピーに現れません（データが失われることはない）。submoduleを更新するリポジトリでは、その操作だけGitに戻ることになります。
- .gitattributes：非対応（issue #53）。改行コードの変換やマージドライバの指定に頼っているリポジトリでは差分が変わります。
逆に、小さな変更を積み重ねて1つずつレビューに出す使い方（スタックしたプルリクエスト）には向いています。下のコミットを直すと上に積んだコミットが自動で付け替えられるため、Gitのように rebase -i を何度もやり直す必要がありません。チームで導入するなら、フックで行っていた検査をCIへ移すのが先です。CIの整備は弊社のDevOps・CI/CD導入支援でも扱っています。試すだけなら既存リポジトリで jj git init し、やめたくなったら .jj ディレクトリを消して git switch main で元のブランチに戻れます。
jjのVS Code拡張・GUI・TUI
jj tui や jj gui というコマンドは存在しません。画面で操作したい場合は、いずれもコミュニティ製の次のツールを入れます（版と更新日は2026年10月24日時点）。
| ツール | 種類 | 最新版（公開日） | ライセンス |
|---|---|---|---|
| Jujutsu Kaizen | VS Code拡張 | 0.11.0（2026-05-29） | MIT |
| VisualJJ | VS Code拡張 | 0.36.1（2026-10-18） | プロプライエタリ |
| Jujutsu X | VS Code拡張 | 1.16.2（2026-10-03） | AGPL-3.0（継承部分はMIT） |
| GG | デスクトップGUI | 0.46.0（2026-10-20） | Apache-2.0 |
| jjui | TUI | 0.10.12（2026-10-17） | MIT |
| lazyjj | TUI（Lazygit風） | 0.6.1（2025-09-10） | Apache-2.0 |
| jj-fzf | TUI（fzfベース） | 0.42.0（2026-08-11） | MPL-2.0 |
VS Code拡張：Jujutsu KaizenとVisualJJ
VS Codeのマーケットプレイスで「jujutsu」と検索すると、呪術廻戦のテーマ拡張が上位に混ざります。拡張機能ビューで拡張IDを指定して探すのが確実です。インストール数は2026年10月24日時点で、Jujutsu Kaizenが約1万、VisualJJが約1.2万です。
- Jujutsu Kaizen（
jjk.jjk）：ソースはGitHubで公開されているMITライセンスの拡張です。作業コピーと親の変更の差分表示、行単位のblame、作業コピーから親への特定行の移動、jj undoと以前の状態への復元に対応します。jj本体は別に入れておく必要があり、PATHに無いときは設定jjk.jjPathで場所を指定します。 - VisualJJ（
visualjj.visualjj）：変更のツリーを専用ビューに出し、split・squash・ドラッグ＆ドロップでの並べ替え・revert・duplicateと、GitHubのプルリクエスト作成までを画面から行えます。jj は内蔵されているため別途のインストールは不要で、Local・WSL・SSH・Dev Containersに対応します。ライセンスはプロプライエタリで、個人の開発者は業務利用でも無料、日常的に使うチーム向けに有料のProがあります。
OSSで揃えたいならJujutsu Kaizen、スタックしたプルリクエストを画面で組みたいならVisualJJです。ただしJujutsu Kaizenは2026年5月以降リリースがありません。VS Code標準のGit表示も同居リポジトリなら動きますが、detached HEADとして出るだけなので、変更の単位で見るには専用の拡張が要ります。
デスクトップGUI：GG
GG（gulbanana/gg）はmacOS・Windows・Linuxで動くデスクトップアプリで、gg web でブラウザ版としても起動できます。版番号を jj 本体に合わせており、0.46.0（10月20日）が最新です。
brew install --cask gg # macOS
winget install --id gulbanana.gg # Windows
cargo install --locked gg-cli # どのOSでもリリースページには .dmg・.msi・.AppImage・.deb・.rpm が並びますが、READMEはLinux向けの配布物を「Windows・macOSほど検証されていない」と書いています。GG自体はjj本体が無くても動きますが、GGが扱わない操作のためにjjも入れておくことを勧めています。
TUI：jjui・lazyjj・jj-fzf
端末向けのjjuiは、2026年10月17日に0.10.12を公開しています。GitHubのスター数は約2,200です。brew install jjui、winget install IbrahimDursun.jjui、Scoopのextrasバケットで入ります。GitでLazygitに慣れている人にはlazyjj（cargo install lazyjj --locked）の画面構成が近いものの、最後のリリースが2025年9月の0.6.1で止まっている点は考慮に入れてください。
よくある質問
Jujutsuの読み方は？Googleの製品ですか？
「ジュジュツ」と読み、コマンド名は jj です。作者はGoogle社員で、Googleでの本人の専任プロジェクトですが、READMEに「Googleのサポート対象製品ではない」と明記されたコミュニティ主導のOSSです。
jjでgit cherry-pickに当たるコマンドは？
jj duplicate <コピー元> -o <コピー先> です。0.46.0で試すと「Duplicated 3995efba19d0 as lvlmxoso a4ae0d7c add b」と表示され、同じ内容・同じメッセージで新しいchange IDのコミットが作られました。コミットを「移動」したいだけなら jj rebase -r <対象> -o <移動先> を使います。
jj logに全部の履歴が表示されないのはなぜ？
既定の表示範囲（revsets.log）が、今の作業コミット、書き換え可能なコミットとその近くの祖先、trunkだけを選ぶ式になっているためです。jj log -r :: で全履歴、jj log -r 'trunk()..@' でメインブランチから今の作業までが出ます。
jjの設定ファイルはどこにありますか？
Linux・macOSは ~/.config/jj/config.toml、Windowsは %APPDATA%\jj\config.toml です。jj config path --user で実際の場所を、jj config edit --user でエディタを開けます。環境変数 JJ_CONFIG を設定するとこれらの場所は読まれなくなります。
Jujutsuをやめて普通のGitに戻せますか？
同居（colocate）で使っていれば戻せます。リポジトリ直下の .jj ディレクトリを削除し、git switch main などでブランチに戻るだけです。jj で作ったコミットは既に .git に書かれているため消えませんが、ブックマークを付けていないコミットはGitからはブランチの無いコミットに見えるので、削除前に jj bookmark create で名前を付けておきます。
