みんなのための柔術

267日前原文(jj-for-everyone.github.io)

概要

Jujutsu バージョン管理システムの初心者向けチュートリアル紹介
Git 経験不要、端末操作が必要
レベル構成 による段階的学習
進捗リセット用の スクリプト 提供
チュートリアルの 継続的な更新 とフィードバック募集

Jujutsuバージョン管理システム入門

Jujutsu は、初心者でも扱いやすい バージョン管理システム
Git や他のVCS経験がなくても問題なし
端末（ターミナル）での操作が前提
- Linux や Mac 推奨、Windowsは WSL 利用を推奨
チュートリアル内で必要な コマンド を順次解説

チュートリアルの読み方と進め方

チュートリアルは レベル（章） ごとに構成
各レベル修了後は実践を推奨
協力作業が目的の場合は レベル1と2 を続けて学習
レベルごとの概要
- 1: 個人作業の最小限知識
- 2: コラボレーションの最小限知識
- 3: 基本的な問題解決（例：コンフリクト解消）
- 4: 履歴の書き換え技術
- 5: 生産性向上・高度なワークフロー
- 6: 特定状況で必要な追加トピック（タグ、サブモジュール等）

進捗リセット方法

チュートリアル進行中に リポジトリ状態 が崩れる場合あり
- 例：練習・実験、PC変更、OS再インストール、意図的な削除、チュートリアル更新
リセットスクリプト で任意の章から再開可能
各章の冒頭に リセットコマンド が記載
スクリプトは 安全性確認 可能、内容は単純なコマンド集

チュートリアルの更新とサポート

チュートリアルと Jujutsu本体 は進化中
最新情報は GitHubリポジトリ の「Watch」→「Custom」→「Releases」で購読
Jujutsu 0.32 （2025年8月時点）に対応
フィードバック歓迎
- typo修正 は「編集」アイコンから
- 改善提案 や体験談はIssueで受付

バージョン管理とは何か、なぜ使うのか

バージョン管理 はソフトウェア開発だけでなく、ドキュメント作成等にも活用可能
変更履歴の 追跡・管理、チームでの 協力作業、過去状態への復元が容易
Jujutsu を使うことで、これらの機能を直感的に体験可能

このチュートリアルは、 Jujutsu によるバージョン管理の基礎から応用までを、初心者にも分かりやすく段階的に学べる構成。進捗リセットや最新情報へのアクセス方法も整備されており、安心して学習を進められる設計。

Hackerたちの意見

JujutsuはGitよりもパワフルだよ。学ぶのが簡単で直感的なのに、実際にはパワーユーザー向けの素晴らしい機能がたくさんあって、Gitを完全に置き去りにしてる。具体的には？これは説明されてないから、なんで使いたいのか気になるけど、ただの空虚な言葉に感じるな。試してみる理由があんまりないよね。

└

同意するよ。既存のGit UIがかなりひどいと思うから、ある程度は彼らに期待をかけてもいいかな。でも、もう少し具体的な情報が欲しいな。特に、これが他の選択肢よりも簡単でパワフルで便利な理由を示してほしい。

└

一例として：マージコンフリクトは適切なエントリーとして提出できて、後で対処できるよ。: https://jj-vcs.github.io/jj/latest/conflicts/

└

こんにちは、著者です。ターゲットオーディエンスはGitの経験がほとんどない人たちなので、詳細な比較は意味がないと思います。GitのUIの奇妙さは、そのパワフルさで正当化されることが多いから、そういう主張をしただけです。だから、この発言は、簡単に学べるツールを選んでもパワーを逃してるわけじゃないって、読者の心を軽くするためのものです。

└

例えば、Mainから始めて、いつかPRになる予定の新しいブランチを作るとするよ。コミット1を作って、次にもう1つ、さらに6つくらい作ったとする。そこで、コミット1の何かが違ってたことに気づく。だから、コミット1を「編集」する。そうすると、他のコミットは自動的にその上にリベースされて、最後のコミットに戻るとちゃんとある。PRの後でも、誰かがコミット3で何かに気づいたら、編集してプッシュすれば修正できる。これらはGitでもできるけど、私はそんなことしたことないし、同僚たちは小さなコミットに分けられたPRを本当に評価してるよ。1つずつ簡単に見直せるからね。

最近Jujutsuについての投稿をいくつか見たけど、特定のワークフローには深入りしてないんだ。Emacs MagitよりJujutsuを使う具体的なメリットってあるの？他のGit UIはあんまり使えなかったけど、MagitのおかげでGitの生産性がかなり上がったし、「Gitの魔法」を実感させられた。Jujutsuはこの体験と競争するつもりなの？それともEmacs以外の（正直、ひどい）Gitユーザー体験の代替として考えられてるの？

└

Jujutsuは本当にGitのUIではなくて、ある意味ではその役割があまり得意じゃない（タグやサブモジュールの作成をサポートしてないなど）。これは全く新しいVCSで、Gitとの互換性があるだけなんだ。GitがSVNに対して安価なブランチをもたらしたように、JJは安価なリベースを提供してる。コンフリクトはもはや世界を止めるような操作ではなくて、リベースやコミットの整理、管理がこれまでとは全く違う方法でできるようになった。スタックされた差分のツールを使ったことがあるなら、JJはすぐに馴染むと思うよ。スタックされた差分のPRを作るのは、jjではほぼ簡単だね。

└

Jujutsuのデザインには「中心的な概念」があるのかな？ Gitの業界標準の地位を考えると、Jujutsuを選ぶ理由が具体的に何なのか理解するのが難しいんだ。これはすごく面白いコンセプトだと思うけど、もう少しターゲットを絞ったマーケティングがあればいいな。もちろん、GitのパワーユーザーがJujutsuの対象じゃないなら、このコメントは関係ないかもね。Gitの大きな弱点の一つは、新しい人に対してフレンドリーじゃないところ（専門用語、深い機能、発見しづらさ、アクセスしやすいGUIフロントエンドの欠如）だから、新しい人が入りやすいVCSソリューションには大きな可能性があると思う。

└

役に立ちそうなリンクをいくつか紹介するね。でも、このトピックについての最近のhnのディスカッションも探ってみる価値があるよ。俺や他の熱心な支持者がたくさんシェアしてるから。素晴らしい「メガマージ」ワークフロー: https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj... https://ofcr.se/jujutsu-merge-workflow そして、jj cliをラップした絶対に素晴らしいTUIもあるよ。今まで使った中で最高のTUIかもしれないし、常に良くなってる。: https://github.com/idursun/jjui

└

jjはmagitのCLIに似ていて、他の人たちにも広まった感じだね。magitから切り替えるメリットはないよ。

└

Magitからjujutsuに切り替えたよ。私にとっての違いは、PRをスタックするのが簡単になったことだけ。小さな変更を意識するようになったし、「出荷する価値がある」と考えるものを縮小するようになった。全体的にはポジティブな体験だけど、Magitがうまくいってるなら、特に価値のあるキラーフィーチャーはないよ。今はhttps://github.com/bolivier/jj-mode.elも使ってて、Emacsの中でjjで必要なことが十分にできてる。

└

もしあなたがすでにヘビーユーザーのMagitなら、基本的なアイデアは多分魅力的に感じるだろうし、jjを使うことでそれらのアイデアをコマンドラインに持ち込めるよ。以前は不可能だと思ってたアクロバティックなこともできるようになるし、多くのユーザーが好きになった機能だよね。例えば、5方向のオクトパスマージをリベースして、まだ解決しなくていいコンフリクトを引き起こす2つの追加のリーフを持つようなやつ。（これは「メガマージ」として知られていて、私がその半ばバカげた名前と共に「発明」した責任があると思ってる。）Magitはjjにとって面白い平行線だと思う。「Gitの魔法」と言うけど、両者にとって「魔法」の多くはGitとはあまり関係なくて、ユーザーに対して露出される「デザイン言語」に関係してると思う。つまり、コミットや差分を操作、ナビゲート、配置するためのツールのことね。GitはMagitとjjのための物理的なストレージ層みたいなもので、それ以上の特別なソースは彼らのアルゴリズムやUX、そして「名詞と動詞」に独特なものがある。私の経験では、Magitユーザーは一般的にjjを売り込むのが難しい。彼らにとってjjはそれほど革命的ではないから。逆に、コマンドラインで5年以上も10スタックのリベースをやり続けてきた熱心なGitパワーユーザーは、売り込むのがとても簡単なんだ。でも、これらのユーザーはコミットグラフ操作のためのよくデザインされたツールの力を理解して評価する傾向がある。Gitのパワーユーザーは、私たちの最もハードコアな信者や支持者の一部なんだ。ちなみに、私はjjのメンテナーの一人で、個人的には結構良いと思ってる。数日間試してみるのもいいかも（Magitを使わずにできればね :)

最近JJをもう一度試して楽しんでるよ。新しいときに試したときは、ちょっと尖りすぎてたけど、今はすごく良くなってる。JJは本当に良いツールの新しい「時代」の一部みたいだね。これについて少しブログに書いたよ。: https://pdx.su/blog/2025-08-13-the-quiet-software-tooling-re...

└

あなたもmiseを使って愛してるって聞いて嬉しい！mise、jj（あなたが言及してたすごいjjui TUI）、それにPython用のuvは、私にとって革命的なツールだよ。本当に美しい道具だね。

└

いい記事だね！ここ数年でツールの基準がかなり上がったと思う。Rustもその一部だね。

└

Bunがこのムーブメントを引っ張ってるんだ。

└

これには絶対にnushellも含めるべきだね。

「Gitの専門家のためのJutustsu」を読みたいな。例えば、コンフリクトのコミット（良いアイデアだと思うけど）が、私の既存のgit rerereをめちゃくちゃにしないかな？それに、ステージドとアンステージドの区別がバカみたいで廃止すべきだと思うけど、git add -pで「好きなパッチの部分だけを意図的にステージする」のは好きなんだ。JJでそんな2パッチ深いパッチセットを作る軽量な方法ってある？無駄にタイムスタンプに触れずに、バカなビルドシステムで余計な再ビルドを引き起こさないようにしたいんだけど。

└

それに、ステージされたものとステージされていないものの区別は馬鹿げてると思う... > git add -pで「好きなパッチの部分だけを意図的にステージする」っていうのは、私には謎の視点だな。十分な$(git worktree && git diff && vi && git apply)があれば、正式に何もステージせずにステージングの動作を実現できるかもしれないけど、うわ、ちょっと確認したら、mercurial 7.1はまだ$(hg add -p)を信じてないみたいだから、彼らの世界ではその「worktree」みたいなやつがインタラクティブに作業を追加する唯一の方法なんだろうね。

最近jjを使ってるって言っておくね。10年前にバージョン管理を始めたときの安全感と自由を感じられるようになったよ。「これはクレイジーなアイデアだけど、今コミットして試してみよう。いつでも戻れるし」っていう感覚だね。

jjを使ってたのは1ヶ月だけだったけど、仕事のプロジェクトでgitに戻ったんだ。jjは本当に良かったけど、それ以上のものは感じなかったな。バニラのgitに戻ったら、数時間でjjの便利さが恋しくなったよ。

└

失ってから初めて感謝することってあるよね。

└

でもそれ以上のものはないって、どういう意味？

Jujutsuはかなり優れてるよ。数ヶ月前に試してみたんだけど（その時のことを書いたし、いくつかの共通パターンについても触れたよ[0]）、それ以来ずっと使ってる。すごく「一貫性のある」体験なんだ。gitには特に問題を感じたことがなかったから（jjを使い続けるとは思わなかった）、もっと高度なことをするにはググる必要があったけど、jjではいくつかのプリミティブに基づいていて、それを組み合わせるのが簡単だから、複雑な履歴の再構成も楽にできる。以前はstash中心のワークフローだったけど、jjの変更の仕方や自動トラッキング、変更間のスイッチができるおかげで、gitよりずっと快適に作業できる。コンフリクト解決を伴うリベースも、一般的にずっとやりやすいし（特にstashのようなワークフローでは）。とにかく、すごくおすすめだし、切り替えに必要な労力はほんとに少ないよ。[0]: https://kubamartin.com/posts/introduction-to-the-jujutsu-vcs...

いい仕事だね！Jujutsuを使い始めてもう5ヶ月近く経つけど、完全にgitを置き換えたよ。実際、そこからGitには52回しか触れてない（--helpの呼び出しを除けば41回だけどxD）に対して、Jujutsuには582回も触れた。特定のワークフローに適応する必要がなくて、Jujutsuはほぼどんなワークフローでもサポートできるほど柔軟なんだ。gitのように使っていても、コミットやブランチを自由に行き来できるし（stashも必要ない）、簡単にリベースできる（これはgitのパワーユーザーには簡単かもしれないけど、VSCodeのgitツールなしでできるのが本当にありがたい）し、余計な頭痛を引き起こさずに作業が進められる。しかも、他の人と同じように実際のgitリポジトリに変更を記録しているから、gitツールとも連携できる。最後に、同僚と違うVCSを使ったのはいつだろう？彼らもそれに切り替えなきゃならなかったことはない？タグやサブモジュール、LFSに関しては少し粗いところがあるけど（他にも見落としてるかも）、試す価値は十分にあるよ。

└

jjuiを試してみて、これからはほとんどjjに触れなくなるよ。すごいよ。

└

git branch --set-upstream-toの代わりは何？

もう何本かの記事を見たけど、jjが素晴らしくてGitよりも全てにおいて優れているって説明してるやつばっかり。今回のチュートリアルもそんな感じだね。良い部分についてはたくさん読んだので、今度は悪い部分や厄介な部分に興味があるな。私のjjの経験はもっとバランスが取れてたから。jjを試したとき、いくつかの痛点があってGitに戻っちゃった。例えば、同僚とブランチを共有してて、準備ができたらすぐにコミットを積み重ねてたんだけど（必要ならpull --rebaseの後にね）。jjには名前付きブランチがないから、そのワークフローはGitでは簡単だけど、jjだと面倒だった – tugエイリアスを使ってもね。このチュートリアルの「リモートブックマークの追跡」章のプロセスも、私にはあまり良く見えない。もう一つの痛点は、jjがgit clone --filter=blob:noneのようなライトクローンと共存できなかったこと。今は修正されてるかもね。

└

https://github.com/jj-vcs/jj/discussions/3549 でtugワークフローを少し簡素化するためのものがあるよ。

└

ちょっと混乱してるんだけど。jjには名前付きブランチがあるよ。それは「ブックマーク」って呼ばれてる。リモートブックマークを追跡すると、jj git fetchでローカルのものがリモートに合わせて更新されるんだ。

└

何度か痛い目に遭ったことがあるのは、jjがランダムに私の変更を失うこと。例えば、Cursorで作業してて、jjのコマンドを実行してないのに（多分jj statusやjj logは実行するけど、他には何も）、後でリポジトリから変更が消えちゃうことがあるんだ（よく古いワークスペースについてのメッセージが出る）。これが私のIDEや巨大なモノレポでの作業、あるいは他の何かに関連しているのかは分からないけど、かなり痛い経験だった。でもそれ以外は、jjが提供する柔軟性は本当に好きだよ。

└

jjには名前付きブランチがないから、手動でjj branch set -r@ XYXを呼び出す必要があるんだ。ちょっと面倒だけど、プッシュする時に一回やればいいだけだよ。それか、jj git push --named XYZ=@を使えばブランチを移動できるよ。

└

もう一つの問題は、jjがgit clone --filter=blob:noneみたいなライトクローンと共存できなかったことだね。今は直ってるかもしれないけど、まだダメみたい。

面白いね。常にオンラインなのに、実はJujutsuのことは聞いたことがなかった。Gitの下で動くより良いVCSのアイデアは好きだよ。そうすれば、GithubやGitlabを使ってコードをバックアップしたり、他の人と共有したりできるからね。FossilやBitkeeperはどちらもすごく良いけど、Gitの人気のネットワーク効果を覆すほど「十分に良い」とは思えなかったから、続けられなかった。これで遊んでみる必要があるな。続けるかどうかは分からないけど、間違ってたら嬉しいな。

ハクソク