個人開発ならjjでいい — Claude Codeと使ってgitの儀式が消えた話

ブランチもステージングもamendも要らない世界

個人開発でClaude Codeを毎日使っている。で、ずっとgitだった。ある日、気まぐれでjj (Jujutsu)を既存のリポジトリに後乗せしてみたら、個人開発の文脈ではgitの儀式が全部要らないことに気づいた。これはその記録。

個人開発におけるgitの違和感

チーム開発ならgitの設計は理にかなっている。featureブランチを切り、PRを出し、レビューを通してmergeする。この流れはgitのbranch / add / commit / pushに綺麗に対応している。

でも個人開発はどうか。

ブランチを切る必要がほとんどない。mainに直接積んでいく
PRレビューがないので、ステージングで「この変更だけcommitする」という作業も不要
コミットメッセージを間違えたらgit commit --amend。でも一度pushしたら使いづらい
作業を一時退避したいときはgit stash。戻すときに衝突したら泣く

つまり個人開発では、gitの機能のうち半分以上はチーム開発のために存在している。一人で使うときは、それらが全部ノイズになる。

jjに乗り換えたら、儀式が全部消えた

jjは「全ての変更が常にコミット」という思想で動く。編集すると勝手に@(ワーキングコピーのコミット)に入っていく。だから以下の概念がそのまま消滅する。

git	jjでは
`git add`	不要。編集したら自動で`@`に入る
`git commit -m`	`jj describe -m`(既存コミットに後付けでメッセージ)
`git commit --amend`	不要。`jj describe`でいつでも書き換え可能
`git stash`	不要。`jj new`で別のコミットを作ればいい
`git rebase -i`	`jj split` / `jj squash` / `jj edit`
featureブランチ	個人開発なら切らない。`main`に直接積む

特にステージング(index)の消滅が大きい。gitだと「この変更はcommitに入れる、あっちは入れない」をgit add -pでちまちまやる必要があったが、jjは全部が常にcommitなので、その判断を後回しにできる。分けたくなったらjj splitで後から切れる。

Claude Codeとの相性が異様にいい

ここが本題。Claude Codeに「pushして」と指示したときの挙動が、jjに変えてから劇的にシンプルになった。

gitの場合のClaude Code

1. git status  (何が変わったか確認)
2. git diff    (内容確認)
3. git add    (どのファイルを入れるか判断)
4. git commit -m "..."       (メッセージを考える)
5. git push

ここで問題になるのがステージング判断。AIが「どのファイルをaddするか」を毎回考える必要がある。複数の論理的変更が混ざっていたらgit add -pで分ける必要すらある。これが地味に面倒だった。

jjの場合のClaude Code

1. jj st                      (何が @ に入ってるか確認)
2. jj describe -m "..."       (メッセージをつける)
3. jj bookmark set main -r @  (bookmarkを今の位置に移動)
4. jj new                     (次の作業用の空コミット)
5. jj git push

コマンド数は同じに見えるが、「何をaddするか」という判断が消えている。全部が@に入っているので、AIは「このコミットをこう分けたい」と思ったらjj splitで後から切れる。前に判断する必要がない。

個人的に一番効いたポイント: Claude Codeに「split判断(atomic commitの分割)」をさせる時、gitだとgit addで先に決めないといけない。jjだと「とりあえずdescribeしてから、必要ならsplitする」という順序で考えられる。思考のステップが一つ減った。

既存gitリポへの後乗せは想像より簡単

「jj入れるには新しくリポ作り直し?」と思っていたが、違った。既存のgitリポに後乗せするだけ。

cd /path/to/existing-git-repo
jj git init --git-repo=.
jj bookmark track main --remote=origin
jj st

これだけ。.gitはそのまま残っていて、裏側でjjが.jjディレクトリを作って並走する。他の人から見たら普通のgitリポのままなので、GitHubもCI/CDも何も変わらない。

~/.config/jj/config.toml にname/emailをグローバル設定しておけば、リポジトリごとの設定は不要。

jj undoという安全網

もう一つ、個人開発で効くのがjj undo。直前の操作を丸ごと取り消せる。

jj rebase -d main   # 間違ってrebaseしてしまった
jj undo             # なかったことにする

gitだとgit reflogで該当のコミットIDを探してgit reset --hardする必要があったが、jjはundo一発。さらにjj op logで全操作履歴が見られるので、どこまでも戻れる。

個人開発だと「あ、やらかした」が頻発する。その時に脳内コストゼロで戻せるのは、一人で試行錯誤する時間を短縮する。

じゃあチーム開発は?

これは別の話だと思っている。チーム開発だとPRレビュー文化がgit前提で回っているし、周りがgitしか知らないならjjを持ち込む理由は薄い。

でも個人開発、特にClaude Codeと二人で回している開発では、jjの「全部コミット・いつでも書き換え可能・undoで戻せる」という思想がそのまま生産性につながる。

結論: 個人開発ならjjでいい。ブランチを切らない・レビューがない・ステージングを使わないという個人開発の実態に、jjの設計がぴたりと噛み合う。既存gitリポへの後乗せも5分で終わるので、試す障壁も低い。

使い始めの基本フロー(メモ)

# 作業する
$EDITOR some_file.ts

# 変更を確認(git statusみたいなもの)
jj st

# 現在のコミット(@)にメッセージをつける
jj describe -m "feat: 何かを実装"

# bookmarkを現在位置に移動(これを忘れるとpushで古い位置が飛ぶ)
jj bookmark set main -r @

# 次の作業用の空コミットを作る
jj new

# push
jj git push

この5ステップを覚えれば、個人開発のgit運用はjjに置き換えられる。git addもgit commit --amendもgit stashも、個人開発の範囲では二度と使わなくていい。