- 新しい バージョン管理システム jj はRustで書かれたプロジェクトで、既存のGitの限界を補い、段階的な導入が可能な構造を持つツールである
- 筆者は過去にRustの成長可能性を分析した経験をもとに、jjもまた 市場適合性・専門チーム・ユーザーベース の面で似た潜在力を持つと評価している
- jjは Gitリポジトリと互換性 を保ちながら、よりシンプルなワークフローを提供し、特にGitの内部構造に慣れていない開発者にとってアクセスしやすい
- GoogleやOxideなどで実際の利用が広がっており、情熱的なコミュニティと献身的な開発チーム が形成されている
- 筆者はjjベースのコラボレーションプラットフォームを開発する ERSC に加わり、Rust初期の頃のようにjjエコシステムの成長を自ら牽引していく計画である
Rustを選んだ理由
- 筆者は2012年のクリスマスにHacker Newsで “Rust 0.5 released” という知らせを見て、この言語に関心を持つようになった
- 当時はRuby on Railsの開発者だったが、大学時代から コンパイラとシステムプログラミング に興味があった
- Rustの成功可能性を判断する際、3つの要素を考慮した: 市場適合性、開発チーム、ユーザーベース
- C/C++を置き換える信頼できる言語がなく、Rustは ガベージコレクションなしでメモリ安全性 を提供する革新的なアプローチを示した
- Mozillaが支援し、FirefoxにRustを導入しようとする計画があったため、実運用の基盤を確保できる可能性が高いと判断した
- Rustコミュニティの 親切で協力的な雰囲気 も魅力的な要因として作用した
- その後、筆者は「Rust for Rubyists」チュートリアルを執筆し、公式ドキュメントの共同著者として参加することになった
jjの登場
- jj(Jujutsu) はプログラミング言語ではなく、新しいバージョン管理システム(VCS) であり、Rustで実装されている
- Gitと互換性があり、既存のリポジトリをそのまま使いながら段階的に導入できる
- 筆者は技術的な好みが似ている開発者 Rain の推薦をきっかけに、jjを探り始めた
- RainはMetaのソース管理チーム出身であり、彼女の推薦は信頼できるシグナルとして受け止められた
- 週末にjjを自ら試しながら、チュートリアル執筆プロジェクト を始めた
- Rustを学んだときと同じように、文章を書くことで概念を整理するやり方で取り組んだ
- 結果として、そのチュートリアルはコミュニティで好意的な反応を得た
jjの将来展望
- 筆者はjjに、初期のRustと似た 成長パターン を見ている
- 市場適合性、チームの力量、ユーザー拡大の可能性のいずれも前向きである
- 市場適合性 の観点ではGitが圧倒的優位にあるが、jjはGitリポジトリをそのまま扱えるため、部分的な導入 が可能である
- Oxide内部でもRainをきっかけに利用が広がり、専用チャンネルができるほど関心が高まっている
- Google内部でもjjが使われて おり、これはMozillaがRustを採用したときと似たシグナルとして解釈されている
- Googleの大規模モノレポ(Piperバックエンド基盤)でも一部プロジェクトがjjを活用しており、これは 社会的証明(social proof) として機能する
- 学習曲線は存在するものの、Gitの内部構造に慣れていないユーザーにとっては、むしろ より直感的でシンプルな使い勝手 を提供する
- Gitの熟練者ほど新しい概念への適応が必要だが、一般の開発者はすばやく慣れる
- jjコミュニティは 情熱的で親しみやすい雰囲気 の中で成長しており、初期のRustコミュニティを思い起こさせる
jjチームとコミュニティ
- 創設者 Martin は長年にわたってjjの開発に献身してきており、最近では個人アカウントから 公式組織アカウントへ移行 し、ガバナンスを整備した
- チームメンバーは ソース管理ツールの開発経験が豊富な専門家たち であり、技術的な方向性と品質管理に強みを持つ
- コミュニティは活発なフィードバックと協業を通じて急速に成長しており、初期Rustコミュニティの前向きなエネルギー を再現している
新たな挑戦: ERSCへの参加
- 筆者は Oxideを離れ、jjベースのコラボレーションプラットフォームを開発するスタートアップERSC に加わることを決めた
- Oxideは素晴らしい職場だったが、jjエコシステムにより深く関わりたいという熱意が決定的な要因となった
- ERSCはjjの上に 開発者コラボレーションプラットフォーム を構築する予定で、GitHubがLogical Awesomeという法人名で出発した事例に触れながら、似たような初期段階を説明している
- 筆者はOxideでの仕事を終えた後に休息を取り、その後はjjコミュニティでの活動とチュートリアルの完成に専念する計画である
- Discordでの活動拡大、ブログ連載、コミュニティへの貢献などを予告している
- 2025年を 新たな転換点 と評価し、自分が本当に情熱を感じるプロジェクトに挑戦できることへの感謝を表している
結論
- 筆者はjjが Rustの成長軌道を再現する潜在力 を持つと確信している
- Gitとの互換性、段階的導入のしやすさ、献身的なチーム、そして活発なコミュニティがその根拠である
- jjは単なるツールを超え、開発者の協業のあり方を革新するプラットフォーム へと発展する可能性を示している
- Rustから始まった筆者の旅路は、いまやjjとともに新たな章へと続いている
2件のコメント
何度も話題になっていたので、一度見てみるべきですね。
Hacker Newsの意見
jjを2回ほど本気で使ってみた。first-class conflict という概念はすばらしいが、実際には衝突解決より staging/commit をはるかに頻繁に行うことになる。magitから来た身としては、jjのhunk分割や選択機能はかなり使いづらく感じた。私はrebaseをよく使うので、magitのrebaseショートカット機能で既にjjの利点の大半を享受していた。私のような人にとって、jjがmagitに勝つにはhunk選択UXを大幅に改善する必要がある
Gitの代替を見るたびに、少し ラッダイト的な感情 を覚える。すでに言語、フレームワーク、ツールが多すぎる。せめてVCSくらいはGitというほぼ普遍的な解決策があるのが救いだと思っている。jjが問題を解決するかもしれないが、業界が両方のシステムをサポートしなければならない負担を考えると、純増にはならない気がする
git-svnでGitを使っていた経験がある。jjも似たようなアプローチのようだ。jjを知らなくても既存のCIやツールはそのまま動くjjを使ってみたが、私は Sublime Merge に慣れている。CLIでバージョン管理をすると反復入力が多く、状態を見失いやすい。GUIなら状態が常に見えていて、ワンクリックでdiffやコミットメッセージ入力ができる。キーボードでhunkを選ぶ作業はもう二度とやりたくない。SMは本当に快適だ。jj GUIが発展するか、SMにjjが統合されるとよい
本当のニュースは、人々が 「jjhub」 のようなものを作り始めたことだ (ersc.io)
Google社内でjjが広がっているらしいが、Googleは定期的に内部VCSを入れ替える傾向がある。git wrapper、mercurial拡張版、そして今はjjまで、この7年の間に全部変わった
jjが 大容量バイナリファイル をgitよりうまく扱えるのか気になる。ゲーム開発の世界では今でもPerforceが王者だ。gitはLFSがあっても十分ではない
1日ほど Jujutsuチュートリアル を試してみたが、かなり良かった。ただ、何か 欠けたパズルのピース がある感覚だった。たとえばGitHubにPRを出すとき、change idが実際に役立つのか気になった。おそらくGoogle社内のPiperバックエンドでのみ真価を発揮するのだろう。ERSCの計画が気になる。個人的には オフラインコードレビュー を内蔵した分散ワークフローがほしい
change-idヘッダーが含まれているので、GitHubがjjを知らなくてもjjユーザー同士ならrebase追跡が可能だ。git cat-file -p HEADで確認できる個人プロジェクトでjjを1〜2か月使ってみたが、かなり満足している。ただ、過去のrevisionを修正するとき、
.gitignoreに新しく追加されたファイルが誤って含まれることがある。それ以外は良い。それでもまだ Gitの知識のほうがはるかに多い ので、会社への導入はゆっくり進めるつもりだ今年 Sapling/Subversionの会社 に加わったが、jjはまだ使っていない。それでもSaplingのほうがずっと 直感的 で、コミットスタックはブランチより理解しやすい。ただ、MetaのレビューUIのような支援がない場合にどうなるのか気になる。こういうプロジェクトはぜひ必要だ
名前が何であれ、East River Source Control は本当に素晴らしい名前だ