- この文書は、Git の経験がなくても進められるように、Jujutsu(VCS) を段階的な レベル構成で教える初心者向けチュートリアルです
- ターミナルの使用を前提としていますが、ターミナルの基礎から扱っており、主要なコマンドは Linux/macOS 中心で説明し、Windows ユーザーには WSL を推奨しています
- 学習の流れは、レベル 1〜3 で 基本・協業・問題解決を固め、上位レベルで 履歴の書き換え・高度なワークフローへ拡張する構成です
- チュートリアルの進行中に状態が崩れた場合に備えて、reset スクリプトで各章の開始地点に戻せる 再現可能な学習環境を提供しています
- なぜ Git ではなく Jujutsu なのかについて、Git 互換性、学習難易度の緩和、高度な機能性を根拠として示しており、最新の Jujutsu 0.32 基準で更新中です
紹介(Introduction)
- このチュートリアルは、Jujutsu を初めて使うユーザー向けの 入門資料です
- 既存の Jujutsu 資料が 熟練 Git ユーザーの移行に集中していた限界を補う、初心者中心のコンテンツを提供します
- ターミナルの使用が基本であり、基本的なターミナルの使い方の章を含み、Windows ユーザーには WSL の使用を推奨しています
読み方(How to read this tutorial)
- 内容は レベル単位で構成されており、各レベルを終えた後に実際に 練習してから次のレベルへ進む学習設計です
- 協業目的であれば、レベル 1 と 2 を 続けて受講することを推奨します
- レベル概要
- レベル 1: 個人作業に必要な 最小のスターターセットを提供し、一人で課題を管理する学生レベルに適しています
- レベル 2: 協業のための最小セットであり、学生のチームプロジェクトや実務開発者に必要です
- レベル 3: 競合解決、復旧などの問題解決の基礎で、平均的な開発者の習熟度に相当します
- レベル 4: 履歴の書き換えで整った履歴を構築し、一部プロジェクトの 品質基準を満たすために必要です
- レベル 5: 生産性ブースター・高度なワークフロー・まれな CLI・理論、Jujutsu マスター段階です
- レベル 6: タグ・サブモジュール・ワークスペースなど状況別のトピックで、必要に応じて参照を推奨します
ショートカットキー(Keyboard shortcuts)
- 左右の矢印キーで 章間の移動に対応しています
- S または / で書籍内の 検索ができます
- ? でヘルプを表示し、Esc で閉じられます
進捗の初期化(Reset your progress)
- 例題リポジトリの状態は 次の章と連動しているため、状態を失うと進行できなくなることがあります
- これを解決するために、章の開始地点へ復旧する reset.sh スクリプトを提供しています
- 各章の冒頭には 正確な reset コマンドが含まれており、コピー＆ペーストで再現できます
- スクリプトは実行前に 内容の確認を推奨しており、実質的には 手動コマンド集レベルの単純な動作です
- スクリプトの主な特徴
JJ_CONFIG=/dev/null で ユーザー設定の影響を遮断- 例題リポジトリの作成、colocate Git 連携、ユーザー情報設定、コミット/プッシュ/フェッチ/リベース など 連続シナリオの再構成
- 各 チャプターのキーワードを引数として受け取り、その地点で 正常終了するように分岐設計
最新状態を保つ(Stay up to date)
- チュートリアルと Jujutsu は 継続的に進化しており、チュートリアルのリポジトリの Releases を購読することで大きな変更通知を受け取れます
- 本チュートリアルは Jujutsu 0.32 基準(2025年8月) で最新であると明記しています
- GitHub で Watch → Custom → Releases から 更新通知を設定する案内があります
バージョン管理はなぜ必要か(What is version control and why use it?)
- ソフトウェアだけでなく Typst などの文書執筆にも適用できる、段階的な作業の蓄積を管理する手段です
- 過去の状態への 復帰が可能で、複数人による同時作業を安全に支援します
- 一般的なバックアップや共同編集エディタより より鋭い制御ツールが必要なとき、Jujutsu が適しています
なぜ Jujutsu なのか(Why Jujutsu instead of Git?)
- Git 互換性: 既存の Git リポジトリと 損失なく相互運用でき、ほとんどの Git 統合ツールをそのまま利用できます
- 学習しやすさ: Git の 複雑で直感的でない UIに比べ、Jujutsu は同じ機能を より低い複雑さで提供します
- より強力な機能性: 学びやすさとは別に パワーユーザー向け機能を多数備え、ワークフローの拡張性を保証します
- 欠点と考慮事項
- 会話では Git 用語中心の文化との 概念マッピングの負担があり、同僚への説明で緩和できる可能性があります
- 比較的新しいため Git の 一部機能が未実装のケースがあり、必要に応じて Git を直接使うことでフォールバックできます
- CLI はまだ 安定化の過程にあり、一部コマンドが変わる可能性があるため、チュートリアルの リリース購読で変化の追跡を推奨します
学習の進め方(Completed & Next)
- 現在は レベル 1〜3 中心に、実践課題の流れ(インストール→初期化→ログ/コミット→リモート/プッシュ・クローン→ブランチ/マージ→リベース→ナビゲーション→取り消し/復旧→競合解決→整理)を体得できるよう構成されています
- 上位レベルで リライト・高度なワークフロー・希少なトピックを追加学習する 段階的な習熟戦略を提示しています
1件のコメント
Hacker News のコメント
jj を褒める記事はもう何十本も見た気がする。今回のチュートリアルも似た感じで、良い点はもう十分読んだので、今は欠点や使いづらい点のほうが気になる。実際に jj を使ってみると長所も短所もあった。私は同僚とブランチを共有してコミットを積み上げていくワークフローをよく使うのだが、jj には名前付きブランチがないので、git より使いにくかった（
tugエイリアスを使っても同じ）。チュートリアルの「Tracking remote bookmarks」の節も、私にはやはり不便そうに見える。もう一つ不便だったのは、jj が git のgit clone --filter=blob:noneのような light clone を使えないことで、これが直ったのか気になるjj には名前付きブランチがあり、jj ではそれを「bookmarks」と呼ぶ。remote bookmark を追跡すれば、
jj git fetchでローカルが remote と同期される私を困らせた点の一つは、jj が変更をランダムに失うことがある点だった。Cursor で作業していて、jj でリポジトリを mutate していないのに（
jj statusやjj logくらいしかしていない）、後で見ると変更が消えていることがあり、しばしば "stale workspace" というメッセージも出ていた。これが IDE や巨大なモノレポのせいなのかは分からないが、本当に苦しかった。それでも jj の柔軟性はかなり気に入っているhttps://github.com/jj-vcs/jj/discussions/3549では、tug ワークフローをもう少し簡単にする議論があるjj に名前付きブランチがないというのは誤り。
jj branch set -r@ XYZのように手動で指定する必要があって少し面倒だが、push のときに一度やればよい。あるいはjj git push --named XYZ=@でブランチを動かすこともできるjj が light clone（
git clone --filter=blob:none）をサポートしていない件は、まだ解決していない「Jujutsu は Git より強力だ」とあるが、具体的に何が強力なのか説明がないので、いったいなぜ使うべきなのか気になる。単なる美辞麗句に見える
チュートリアルの著者です。初心者向けなので、Git との詳細な比較は適切ではなかった。Git UI の複雑さはしばしば「高機能だから」で正当化されるので、Jujutsu は学びやすい代わりに機能を失っているわけではない、という点を伝えたくてその一文を添えた
例えば Main ブランチから新しいブランチを作って、後で PR に送る予定だとする。コミットをいくつも積み重ねたあとで、1番目のコミットを直す必要があると気づいたら、1番目を修正して保存するだけで、ほかのすべてのコミットが自動的に最新状態へリベースされる。PR の後でも 3番目のコミットを修正したければ、そのコミットだけ編集して push すれば終わり。こういう作業を Git で直接やるのは本当に難しい。同僚たちは複数コミットに分かれた PR をとても気に入っている
私もだいたい同じ意見。Git UI は全体的に物足りないと感じているので、jj はある程度信頼して使う気がある。ただ、「なぜより簡単・強力・便利なのか」を具体的に示すデモがあればもっと良かった
一つの例として、マージコンフリクトを 1 つの項目として記録しておき、あとで処理できる: https://jj-vcs.github.io/jj/latest/conflicts/
最近また JJ を使ってみたらかなり良くなっていて、楽しく使っている。初期に試したときは粗さが多くて負担だったが、JJ は最近登場している優れたツーリングの「新しい波」の一部だと思う。ブログにも書いた: https://pdx.su/blog/2025-08-13-the-quiet-software-tooling-renaissance/
良い記事だと思う。ここ数年で開発ツーリングの基準は本当に高くなった。Rust もそうした変化の一部だ
あなたも mise を使って気に入っていると知れてうれしい。mise、jj（それに最高にクールな jjui TUI）、Python 向けの uv はどれも革新的だ。こういうツールは本当に美しいと思う
私はここに nushell もぜひ加えたい
Bun もこのツーリング革新の先頭を走っている
素晴らしい仕事だ！ 私はこの 5 か月近く、Jujutsu だけを使って git を完全に置き換えた。実際、この間 Git は 52 回しか実行しておらず（そのうち 11 回は
--help）、Jujutsu は 582 回も使っている。特定のワークフローに合わせる必要はなく、Jujutsu はほぼあらゆるワークフローを支えられるだけの柔軟性がある。git のように使うとしても、コミットやブランチを自由に動かせるし（stash は不要）、簡単にリベースできる（git の達人には当たり前かもしれないが、VSCode の git ツール抜きでそのままできるのが本当にありがたい）。VCS 由来の面倒事に悩まされず、作業そのものに集中できる。注意点として、履歴は従来どおり git リポジトリにも残るので、ほかの git ツールとも互換性がある。つまり同僚が VCS を変えなくても、自分だけ別のものを使えるわけだ。タグ、サブモジュール、LFS 周りには少し物足りない部分があるが、それでも試す価値は十分あるgit branch --set-upstream-toの jj における代替が何なのか気になるjjui を使えば、今後は jj コマンドをほとんど触らなくなる。ほんとうに驚く
Jujutsu は本当に良い。数か月前に使ってみて関連する記事もいくつか書いた（この記事 など）が、その後もずっと使い続けている。全体としてとても「一貫した」体験だ。私はもともと git も問題なく使っていたが、jj はすべてがいくつかの基本原理で回っていて、好きなように組み合わせて複雑な履歴変更も簡単にできる。私は以前は「stash 中心」で作業していたが、jj は変更の自動追跡や自由な変更移動のおかげで git よりはるかに快適だ。リベースや衝突解決も（特に stash スタイルのワークフローでは）ずっと良い。強く勧めたいし、移行に必要な労力もとても小さい
個人的には、git の上に新しいレイヤーを足すというアプローチはあまり好きではない。git の覇権を崩すのが難しいのは分かるが、完全に新しい土台の上に作るほうが、ずっと強力で自由になれると思う
私は 1 か月ほど jj を使ったあと、会社の特定プロジェクトのために git に戻った。jj は本当に気に入ってはいたが、それ以上ではなかった。でも git に戻って数時間もしないうちに、jj の便利さが猛烈に恋しくなった: https://blog.nawaz.org/posts/2025/Aug/the-jujutsu-effect/
「それ以上ではなかった」というのが具体的にどういう意味なのか気になる
失って初めて価値が分かる、という話だ
「Git エキスパートのための Jujutsu」というテーマでもっと読みたい。例えば、conflict をコミットすることで自分の git rerere を壊さないのかとか、git では
git add -pでパッチの一部だけをステージして作業するのが好きなのだが、jj で 2 段階のパッチセットを手軽に実現する方法があるのかが気になる。タイムスタンプ破損や無意味なビルドシステムの再ビルドも避けたいjj で最も広く使われているワークフロー（「squash workflow」）で答える。作業ディレクトリである top commit で自由に変更しておいて、「ステージング」したくなったら一つ下のコミットへ squash down すればいい（全変更でも、
-iで一部だけ選んでもよい）。またsquash --intoで別のコミットを指定して、好きな位置へ squash することもできる@がワークスペースで、@-が作業中のコミット。jj squash -iを使えば、diff の一部だけを対話的に@へ戻せる「ステージ／アンステージの区別は不要だ」に同意しつつも、「パッチの気に入った部分だけステージするのは本当に良い」という意見は面白い。git worktree、git diff、vi、git apply の組み合わせでステージングなしでも似た効果は出せるが、本当に面倒だ。mercurial 7.1 にもまだ対話的追加はなく、worktree を使った裏技以外に代替がない
最近 Jujutsu の話を見かけるが、具体的なワークフローまでは追っていない。Emacs Magit と比べて、Jujutsu に特別な利点があるのか気になる。これまで使った Git UI の多くは物足りなかったが、Magit のおかげで git の生産性はかなり上がり、git の「魔法」も実感できた。Jujutsu はこの体験と競合しようとしているのか、それとも（本当に物足りない）既存の git UI の代替を目指しているのか知りたい
Jujutsu は単なる git UI ではなく、むしろ git UI としては弱い部類だ（タグ、サブモジュールなどのサポート不足）。完全に新しい VCS だが、バックエンドに git を使っている。git が SVN に対して「cheap branch」をもたらしたとすれば、JJ は「cheap rebase」をもたらす。コンフリクトが作業全体を止めないし、リベースやコミット構造の管理が本当に楽だ。stacked diffs を使ったことがあるならしっくり来るはずで、stacked diff PR は jj ならほぼ手間なくできる
すでに Magit を多用しているユーザーなら、jj の基本コンセプトにも魅力を感じるはず。jj では、これまで不可能だと思っていたようなコミットのアクロバット（例えば、5-way octopus merge の 2 つのリーフを、コンフリクト未解決のままリベースすること）ができる。これは私が作った「Mega Merge」という手法でもある。Magit と jj には似ている点があって、いわゆる「git の魔法」も実際にはツールの「デザイン言語」によるところが大きいと思う。Git は Magit と jj の物理ストレージ層にすぎず、アルゴリズム・UX・概念は大きく違う。Magit ユーザーは jj にそこまで衝撃を受けない傾向があるが、高度な Git コマンドラインユーザーは jj へ非常にスムーズに移行し、実際に強力な伝道者になる。コミットグラフを操作するツールの力を誰よりよく理解している人たちだからだ。参考までに、私は jj のメンテナーの一人で、本当によくできたツールだと思っている。数日だけでも Magit なしで使ってみるといい
関連リンクを置いておく。Megamerge ワークフローをよく説明した記事: https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj-absorb/、https://ofcr.se/jujutsu-merge-workflow、それから jj cli を包む最高レベルの TUI: https://github.com/idursun/jjui
Jujutsu の「中心概念」が何なのか気になる。Git が業界標準であることを踏まえると、Jujutsu を使うだけの強い理由がまだピンとこない。コンセプト自体は面白いと思うが、もう少し明確なマーケティング視点があれば採用可能性はもっと高まりそうだ。Git の最大の弱点は、部外者に対してあまりにも不親切なことだと思う（専門用語、発見しづらさ、GUI フロントエンド不足など）。だから初心者に優しい VCS には大きな可能性があると思う
Magit から jujutsu に乗り換えた。変わったのは、PR を積み上げるのがずっと簡単になったことと、変更をより小さな単位に分ける習慣がついて、「送る価値があるか」の基準が厳しくなったことだ。概ね良い体験だったが、すでに Magit が十分合っているなら、決定的な強みはない。それでも https://github.com/bolivier/jj-mode.el のおかげで、Emacs でも jj を十分使える
面白そうだ。オンラインでかなり活動しているのに、Jujutsu のことは今回初めて知った。Git をバックエンドに使いながら、より良い VCS を提供するという発想が気に入った。理由の一つは、依然として Github-Gitlab にバックアップや共有ができるからだ。Fossil や Bitkeeper にも魅力はあるが、git より「十分に」優れているわけではなく、git のネットワーク効果を覆せていない。Jujutsu も少し触ってみようと思う。使い続けるかは分からないが、思った以上に良ければうれしい