Git worktreeからjjへ: 変更の扱いを変えてハッピーになる
はじめに
Git worktreeは、並行作業の摩擦を減らすための強い手段だ。けれど、作業が増えるほど「分ける」こと自体が疲労になる。jjはその疲労を別の構造で受け止める。
この記事は、Git worktreeを使ってきた人が、jjとの違いと移行の考え方を理解し、無理なくハッピーに移れるように書く。
jjは「変更」を中心に据える
Gitはコミットが中心だ。変更はコミットに吸い上げられ、そこで初めて意味づけされる。だから、分割や修正は「コミットを整える作業」になりやすい。
jjは逆向きだ。変更が先に存在し、後から意味づけ（describe）する。この順序の違いが、作業の心理的コストを変える。
Gitとの違いを短く整理する
ステージングの感覚が変わる
Gitではステージングが「編集とコミットの間の関所」になる。jjでは、変更は最初から並列に存在するので、その関所が前面に出てこない。代わりに、jj splitで「いま分ける」を自然に行える。
「整える」のタイミングが後ろに移動する
Gitでは、コミットをきれいにするために早めの分割やrebaseを意識する。jjでは、変更が蓄積してからでも分けられるので、整える作業が後ろに寄る。
変更の意図が残りやすい
jj describe -m "..."は、変更に意味を与える行為そのものだ。修正後に意図を残すより、意図を残すことが修正の一部になる。
Git worktreeとの違い
結論だけ先に言うと、Git worktreeは「環境を分ける」手段で、jjは「変更を分ける」手段だ。
- worktreeは、複数ブランチを物理的に分けて同時に触る
- jjは、1つの作業場所で変更を並列に扱う
まだworktreeが有効な場面
jjに移行しても、以下のケースではworktreeが合理的だ。
- 依存関係のバージョンが作業ごとに大きく違う
- ビルド成果物がディレクトリに強く結びついている
- 大きなデータや長いビルドがキャッシュ前提
逆に言えば、論理的な並行作業が目的なら、jjのほうが軽い。
移行の考え方: 手順よりも順序
移行は「いきなり全部置き換える」より、順序を変えるところから始めると楽になる。
1. まずは観察系コマンドだけ使う
作業の途中で以下だけ実行する。これだけで「変更の見え方」が変わる。
jj status
jj diff
jj log -r @ -n 5
2. 変更の分割を後ろに置く
一度まとめて変更を作ってから、必要になった時点で分ける。
jj split
この「後から分けても間に合う」感覚が、jjの強さだ。
3. 意図を残すタイミングを変える
作業が一段落したときに、意図を記録する。
jj describe -m "Explain why this change exists"
4. PRはブックマーク中心で流す
OpenCode前提なら、以下の流れが最短だ。
jj bookmark create -r @ pr/jj-migration
jj git push --bookmark pr/jj-migration
gh pr create --head pr/jj-migration --base main
OpenCodeとjjの相性
OpenCodeは「安全な作業単位」と「明示的な操作」を好む。jjのモデルはそれと一致している。
- 変更が常に見えるので、作業範囲が明確になる
-
splitとdescribeで、意図と変更の境界を保てる - PR対象の切り出しがやりやすい
結果として、作業が一本道にならず、戻りやすい。
どうしたらハッピーになれるか
ハッピーの条件は「操作が減ること」ではなく「不安が減ること」だと思う。
- 分割の遅れが怖くない
- 履歴の整形が義務にならない
- 変更の意図が後からでも掴める
jjは、これらを構造で支える。だから、運用の努力を減らしても破綻しにくい。
まとめ
Git worktreeは「環境を分ける」ことで並行作業の負荷を下げる。jjは「変更を分ける」ことで思考の負荷を下げる。移行は機能比較ではなく、作業の順序を変えることから始めるといい。
最初は観察だけでも十分だ。小さく使い始めて、戻りやすさを体験できれば、自然とハッピーに近づく。
Discussion