次世代のVCS！Jujutsu（jj）コマンドラインツールの衝撃

Jujutsu（jj）は、Googleで開発が進められている次世代の分散型バージョン管理システム（VCS）です。Gitとの高い互換性を持ちつつ、Gitの複雑な操作性を劇的に改善することを目指しています。強力なアトミック操作や直感的なコマンド体系が特徴で、Gitユーザーなら一度触ればその快適さに驚くはずです。

最後の段落が一番重要かもしれないな。

jj を試してみるべき理由がもう一つある。git 互換のバックエンドを持っているから、自分一人で jj を使うことができるんだ。一緒に仕事をしている他の誰かに乗り換えを強要する必要はない。つまり、試してみるデメリットは実質ゼロってことだ。もし合わなかったとしても、jj で書いた履歴をすべて失うわけじゃないし、問題なくすぐに git に戻れる。

jj を試しているところだけど、気に入らない点が一つある。ファイルの編集が自動的にコミットされてしまうから、変更のためにわざわざ空のコミットを防御的に作成しなきゃいけないんだ。例えば、2週間前のコミットからリポジトリをブラウズしたいとする。そのコミットをチェックアウトしてファイルを編集すると、自動的にそのコミットがリポジトリ内で変更されて、それ以降のすべての履歴が新しい変更の上にリベースされてしまう。だから、古いコミットから新しいブランチを作って、そこに空のコミットを追加しなきゃいけない。そうしないと、ファイルの変更で過去2週間の履歴を書き換えてしまうことになる。git の方がずっといいよ。ファイルをどういじろうが、「自分が指示する」まではリポジトリが勝手に変わることはないからね。

jj って、逆方向に考えることを求めてくるのかな？新しい変更を始めてから description をつけるように言われるけど、git だと最後にワークフローの締めとしてチェンジセットに名前をつける形だしな。

それに、複数の異なる機能や抽象化に関する変更が混ざった、汚れたリポジトリ状態になってしまうこともよくある。たいていはコミットしたい変更だけを選んで状態をクリーンにするんだけど。

git 互換だから、ファイルを add してコミットせずに保持する運用もできるはずだよね。でも、チュートリアルを読んだだけだとそのあたりが確信持てないんだ。

「より強力で簡単」っていうのは素晴らしい売り文句だけど、それがどんな苦労を減らしてくれるのか、あるいはそれがないとどんな損をしているのか、納得させてくれる具体例がトップページに欲しいな。

jj の機能で一番気に入っているのは「jj absorb」だな。

現在のリビジョンで行った変更について、その近辺を修正した最後のコミットを探し出して、変更をそこに移動してくれるんだ。

設定ファイルや .gitignore の変更を忘れたときなんか、本当に便利。「jj new」して修正して「jj absorb」するだけ。新しいコミットを作ったり、どこにリベースすべきか悩んだりする必要はもうない。

それに、今さらマージコンフリクトに対処しなくていいのは最高だね。自分のリポジトリにはまだ数ヶ月前のマージコンフリクトが残ったままだよ。もう解決する気もないから、そのうちブランチごと消すつもりだ。

やあ！

チュートリアルをしばらく更新できていなくて申し訳ない。アップストリームに取り込むつもりはあるんだけど、今働いている ersc.io というスタートアップがめちゃくちゃ忙しくて、なかなか手が回らなくてね。自分自身は毎日 jj を使っていて、とても気に入っているよ。

質問があれば何でも答えるから言ってくれ！

メンタルモデルは C言語と Python の違いに近いと思う。Git は過去へのフォレンジックトレースを提供するけど、jj は章立てされた物語を提供してくれる。裏側を覗けば状態遷移のフォレンジックマップが見えるのは変わらないけど、普段ナビゲートしたいのはそういうものじゃないんだ。時々、最新の章を納得させるために、初期の章を書き直す必要があることもあるしね。

jj を試してみる価値がある理由の一つは、単に「git とは違う」という点にあると思う。複数のやり方を知ることは良いことだよ。

たとえ採用しなかったとしても（自分は採用しなかったけど）、「このやり方しかない」と思い込んでしまうのは簡単だ。自分の好みのシステム以外が、どうやってワークフローや問題を管理しているかを知ることは、視点を広げるために非常に有用だよ。

だからといって何でもかんでも試せってわけじゃないけど（誰だって時間は限られているからね）、優れたエンジニアであるためには、愛されている機能的なワークフローの選択肢やトレードオフを理解しておくことが大事なんじゃないかな。

jj のおかげで、トランクベース開発のワークフローにおいて非線形の DAG を扱うことにかなり抵抗がなくなった。同じ親を持つ複数の変更や、複数の異なる親を持つ変更などね。

以前は、成果物に不必要な順序付けをする癖があったんだ。論理的に B と C の順序を入れ替え可能だったとしても、変更のスタックを A -> B -> C -> D のようにしていた。

jj は競合やマージの処理の仕方が優秀だから、DAG を扱うのが簡単なんだ。今では、変更が何に依存しているかを、より正確に、より表現豊かに書けるようになったと感じる。そのおかげでレビューや提出も効率的になったよ。

議論の多くが git との違いや、内部で git のストレージ戦略をどう使っているかに集中しているけど、正直なところ、そんなことは全部無視していいと思う。git のことは考えないでほしい。日々の作業に使えるワークフローはこんな感じだ。

クリーンなリポジトリで：

$ jj
Working copy (@) : abcdef a53ff9ba (empty) (no description set)
Parent commit (@-): qrstuv 4bc1bf34 the last thing you did

変更を加える。

$ jj # ステータス（新規、変更、削除、移動など）が表示される

変更に満足したら、

$ jj commit -m "made changes"

これで jj はクリーンな状態に戻る。線形で作業し続けるためにわざわざ「jj new」する必要はない。ただ次の変更を加えてコミットすればいい。もし失敗したと気づいたら、修正して「jj squash」すれば、最後のコミットに統合されるよ。

「jj new -r lmnop」を使うのは、前回のコミットではなく、リビジョン lmnop のコードベースの状態に基づいて作業したいときだけだ。つまり、擬似的なブランチを作るようなものだね。手動でブランチを作って名前をつける必要なんてないんだ。

git の履歴に関しては、「git log」を打てば実際に何が起きているか分かるはず。jj の commit が反映された綺麗な履歴になっているよ。jj の内部処理でやっているあれこれなんて見えないから大丈夫。