コミットしていない変更を抱えたままブランチを切り替えられず git stash を打つ。git add -p でインデックスに何を載せたか分からなくなる。rebase の途中でコンフリクトに詰まり、結局 git rebase --abort に逃げる。Gitを何年使っていても、この手の操作は毎回どこか緊張します。
そうした「Gitの使いにくさ」を、リポジトリ形式ごと捨てずに作り直したのがJujutsu（ジュジュツ、コマンド名は jj ）です。保存先には普段のGitリポジトリをそのまま使うため、GitHubやGitLabに対しては通常のGitクライアントとして振る舞います。つまりチーム全員を巻き込まずに、自分の手元だけ差し替えて試せます。
本記事では、Jujutsuが何を変えたのか、既存のGitリポジトリでどう導入するのか、そして本番の開発フローに入れる前に確認しておくべき制約を、公式ドキュメントとリポジトリの記述をもとに整理します（公式サイト: https://jj-vcs.dev ）。
- この記事でわかること：Jujutsuの位置づけと、Gitとどう共存するのか。
- 「作業コピーがコミット」という中心的な設計と、そこから消える概念（インデックス・stash）。
- 操作ログによるundo、コンフリクトを抱えたままコミットできる仕組み。
- 既存Gitリポジトリへの導入手順と、対応していないGit機能・導入判断の材料。
Jujutsuとは？Gitリポジトリをそのまま使う別のバージョン管理システム
Jujutsuは、Rustで書かれたオープンソースのバージョン管理システムです。ライセンスはApache License 2.0で、開発はGitHubの jj-vcs/jj で公開されています（リポジトリ: https://github.com/jj-vcs/jj ）。2020年から公開されており、2026年8月時点で3万を超えるスターが付いています。
設計上の特徴は、ユーザーインターフェースとアルゴリズムを、実際にデータを保存する層から切り離している点です。公式リポジトリの説明では、この抽象化によって将来的にMercurialやBreezy、Googleのクラウド型設計であるPiper/CitCのような複数のバックエンドを扱えるとされています。ただし現時点で本番利用に耐えるバックエンドはGitのみで、実装にはRust製のgitoxideライブラリが使われています。
重要なのは、この「Gitバックエンド」が翻訳レイヤーではなく、実際のGitリポジトリそのものだという点です。jj で作ったコミットは通常のGitコミットとして保存され、Gitリモートからのfetchもpushもできます。いつでもGitのCLIに戻れるため、チームの他メンバーは誰かがJujutsuを使っていることに気づく必要すらありません。
一方で、Gitに保存されるのはコミットとファイルだけです。ブックマーク（Jujutsuにおけるブランチ相当）や操作ログといった上位のメタデータは、Gitの外にある独自のストレージに保存されます。この分離が、後述するundoや自動リベースを可能にしています。
Gitとの違い①：作業コピーがコミットで、ステージングエリアがない
Jujutsuで最初に戸惑うのは、作業中のファイルそのものが常に1つのコミットとして扱われる点です。ほぼすべての jj コマンドは実行時に作業コピーをスナップショットし、現在の作業コピーコミットを自動的に修正（amend）します。編集して保存した瞬間に、それはもう「未コミットの変更」ではなく、コミットの中身になります。
この設計から、Gitでおなじみのいくつかの概念が丸ごと消えます。インデックス（ステージングエリア）は不要になり、公式のGit比較ドキュメントでも「作業コピーが自動的にコミットされるため、インデックスに相当する概念は意味をなさない」と説明されています。同様に git stash も要りません。作業コピーが常にコミットである以上、退避すべき「汚れた状態」が存在しないからです。
その代わりに使うのが、コミットを直接操作するコマンド群です。変更の一部を切り出したいときは jj split、隣のコミットに変更を移したいときは jj squash を使います。Gitでは「コミットする前にインデックスで選別する」順序だったものが、「まずコミットしてから、後で切り分ける」順序に入れ替わると考えると分かりやすいはずです。
ブランチの扱いも変わります。Jujutsuではブランチ名を付けなくてもコミットグラフのすべての先端（leaf）が保持されるため、Mercurialと同様の「匿名ブランチ」で作業できます。小さな試行のたびに名前を考える必要はなく、共有する段になって初めてブックマーク（jj bookmark）という名前を付ければ済みます。
やりたいこと | Gitでの操作 | Jujutsuでの操作 |
|---|---|---|
作業を一時退避する | git stash / git stash pop | 不要（作業コピーが常にコミット） |
変更の一部だけをコミットする | git add -p → git commit | そのまま作業し、後から jj split |
直前のコミットに修正を足す | git commit --amend | jj squash（自動amendも働く） |
ブランチを切って試す | git switch -c 名前 | jj new（名前は不要、必要になったら jj bookmark） |
直前の操作を取り消す | git reflog を読んで git reset | jj undo / jj op log |
Gitとの違い②：操作ログによるundoと、コンフリクトを抱えたままのコミット
Jujutsuは、コミットだけでなくリポジトリに対して行われたすべての操作を記録します。コミット、fetch、pushはもちろん、リベースやブックマークの移動も対象です。jj op log で履歴を確認でき、jj undo で直前の操作を取り消せます。Gitのreflogに似ていますが、公式ドキュメントは「操作ログはreflogに似ているが、はるかに強力である」と述べています。すべての参照の更新をひとまとまりの操作としてアトミックに記録するため、複数のブランチをまたぐ操作でも一発で元に戻せるからです。
もうひとつの大きな違いがコンフリクトの扱いです。Jujutsuはコンフリクトをコミットと同じ「第一級のオブジェクト」としてモデル化しています。Git比較ドキュメントの表現では「マージコンフリクトが原因で失敗するコマンドは存在しない。コンフリクトは代わりにコミットに記録され、後から解決できる」となります。リベースの途中で手が止まり、中断するか強行するかを迫られる、という状況が起きません。
この2つは組み合わさると効いてきます。Jujutsuでは、あるコミットを修正すると、その子孫コミットが自動的に新しい親の上へリベースされます。さらにコンフリクトを解決すると、その解決内容も子孫へ伝播します。公式リポジトリはこれを「git rebase --update-refs と git rerere を組み合わせたものを、設計として完全に透過的に実現したもの」と説明しています。積み上げたコミット列の途中を直す作業が、Gitより大幅に軽くなります。
コミットの選択には、MercurialやSaplingから取り入れられたrevset言語が使えます。「このブックマークから見て未マージのコミット」といった条件を式で書けるため、log表示や一括リベースの対象指定が宣言的になります（revsetの仕様: https://docs.jj-vcs.dev/latest/revsets/ ）。
導入方法：既存のGitリポジトリにそのまま重ねる
インストールはパッケージマネージャー経由が中心です。macOSとLinuxのHomebrew、Windowsのwingetとscoop、Arch Linuxのpacman、Fedoraのdnf（COPR）、openSUSEのzypper、Nix flakes、FreeBSDのpkgなどが用意されています。cargoでソースからビルドする場合はRust 1.88以上が必要です。また実行時にGit 2.41.0以上を要求するため、Debian 11やUbuntu 22.04ではGit側の更新が必要になることがあります（手順: https://docs.jj-vcs.dev/latest/install-and-setup/ ）。
インストール後は、コミットに刻まれる名前とメールアドレスを jj config set --user user.name および user.email で設定します。ここはGitの設定を自動で引き継がないため、最初に忘れず行ってください。
実際の導入で押さえるべきは「コロケート（colocated）ワークスペース」という考え方です。jj git init や jj git clone で作られるワークスペースは既定でコロケート構成になり、.jj ディレクトリと .git ディレクトリが同じ作業コピーを共有します。jj コマンドを実行するたびにGitリポジトリとの読み書きが自動で行われるため、jj と git のコマンドを好きな順序で混ぜて使えます。
この性質のおかげで、移行は段階的に進められます。まずは普段のリポジトリでコロケート構成にして jj log や jj status を眺め、慣れてきたら jj new と jj squash に手を伸ばし、どうしても分からないときは git のコマンドに戻る、という進め方ができます。既存のリポジトリを別形式へ変換する必要も、チーム全体で足並みを揃える必要もありません。
- 空のリポジトリを作る：jj git init <名前>（.jj と .git の両方が作られる）
- リモートから取得する：jj git clone <URL>（リモート名は既定で origin、--remote で変更可能）
- 手元のGitリポジトリを使う：jj git init --git-repo=<Gitリポジトリのパス> <名前>
- コロケートを使わない構成にする：jj git init / jj git clone に --no-colocate、または設定で git.colocate = false
- 既存ワークスペースの構成を切り替える：jj git colocation enable / disable
導入前に確認すべき制約と判断材料
Jujutsuは日常の開発に十分使える完成度に達している一方で、公式リポジトリは今も明確に「実験的なバージョン管理システム」と位置づけています。README冒頭の注意書きは、Git互換性は安定しており大半の開発者が日々の作業すべてに使えている一方で、作りかけの機能や洗練されていないUX、ワークフロー上の欠落が残っており、用途によっては使えない可能性があると述べています。
バージョンも0.x系のままで、最新版は2026年8月6日公開の v0.44.0 です。おおむね月に1回のペースでリリースされ、v0.44.0ではタグのfetch／pushが安定化された一方、jj git fetch のタグ取得の挙動が変わるなどの破壊的変更も同時に入りました。1.0に向けたロードマップにはコピー・リネームの追跡、GitHub／GitLabなどのフォージ連携、サブモジュール対応、大容量ファイル対応などが並んでいますが、公式ロードマップは貢献者の多くが余暇で開発しているため各目標に期日を設定できないと明記しています（ロードマップ: https://docs.jj-vcs.dev/latest/roadmap/ ）。
運用面で特に効いてくるのは、対応していないGit機能です。CIやチーム規約が下記のいずれかに依存している場合、Jujutsuだけで完結させることはできません。コロケート構成であればGitのコマンドを併用して回避できるケースもありますが、事前に洗い出しておくべきです（対応状況の一覧: https://docs.jj-vcs.dev/latest/git-compatibility/ ）。
- Gitフック：未対応。pre-commitなどのフックに依存した検査は、jj のコマンドだけでは実行されない。
- Git LFS：未対応。大容量ファイルをLFSで管理しているリポジトリは対象外。
- サブモジュール：未対応。作業コピーに現れないが、失われることもない。
- .gitattributes：未対応。改行コードの正規化などをこれで制御している場合は注意が必要。
- 部分クローン：未対応。シャロークローンは一部動作するが、深さを広げる操作は未対応で問題を起こす。
- タグ：一部対応。軽量タグの作成とタグ付きコミットのチェックアウトはできるが、注釈付きタグは作成できない。
- git-worktree・sparse checkout：非対応だが、jj workspace と jj sparse という独自の代替がある。
- Gitの設定：一部のみ反映。リモート定義と core.excludesFile 以外の .gitconfig は読まれない。
まとめ：手元だけで試せるので、判断は実際に触ってからでよい
Jujutsuは、Gitのリポジトリ形式と互換性を保ったまま、その上のユーザー体験を設計し直したバージョン管理システムです。作業コピーをコミットとして扱うことでインデックスとstashを消し、操作ログですべての操作を取り消し可能にし、コンフリクトをコミットの中に持てるようにしました。積み上げたコミット列を頻繁に組み替えるような開発では、Gitより明確に手数が減ります。
同時に、0.x系で破壊的変更が入りうること、フックやLFS、サブモジュールに未対応であることは、チーム導入を判断するうえで無視できません。まずは既存リポジトリをコロケート構成にして個人の作業で試し、CIやレビュー運用が依存している機能に触れないかを確認するのが現実的な進め方です。合わなければ .jj ディレクトリを消すだけで元のGitリポジトリに戻せます。
なお、Jujutsuの開発は作者のMartin von Zweigbergk氏がGoogleで専任として取り組んでおり、他のGoogle社員も開発に加わっています。ただしリポジトリには「これはGoogleがサポートする製品ではない」と明記されており、サポートはコミュニティによって提供されます。この点も含めて、下記の一次情報で最新の状況を確認してください。
参考リンク
- Jujutsu 公式サイト
- https://jj-vcs.dev
- 公式ドキュメント（最新リリース）
- https://docs.jj-vcs.dev/latest/
- GitHub リポジトリ（README・ライセンス）
- https://github.com/jj-vcs/jj
- Git との比較（コマンド対応表を含む）
- https://docs.jj-vcs.dev/latest/git-comparison/
- Git 互換性・対応していない機能の一覧
- https://docs.jj-vcs.dev/latest/git-compatibility/
- インストールと初期設定
- https://docs.jj-vcs.dev/latest/install-and-setup/
- 開発ロードマップ
- https://docs.jj-vcs.dev/latest/roadmap/
- リリース一覧（v0.44.0 のリリースノート含む）
- https://github.com/jj-vcs/jj/releases
