Jujutsu入門：Git互換のまま履歴編集をやり直す

Jujutsuは、Git repositoryへ別の操作模型を持ち込む

Jujutsu、command名jjは、Git repositoryと相互運用できるversion control systemだ。branchをcheckoutし、staging areaへaddし、commitするGitの操作模型とは違い、working copy自体を常に一つのcommitとして扱う。fileを編集すると現在のchangeへ自動的に反映され、jj newで次のchangeを始める。

内部ではchange IDとcommit IDを分け、rebaseやamendでcommit IDが変わっても、同じ論理的changeとして追跡しやすい。履歴編集を特別な危険操作ではなく日常操作として扱い、操作そのものもoperation logへ記録する。Gitを捨てるのではなく、Git backendとGitHubを使いながらlocal workflowを変えられる点が特徴だ。

Git経験者が最初につまずく三つの違い

第一にstaging areaがない。編集は現在のworking-copy commitへ入る。第二にGitのbranchに近い名前はbookmarkだが、新しいcommitを作ってもbookmarkは自動で進まない。第三にworking copyには通常、まだdescriptionのないcommitが存在する。jj commit -mは現在のchangeへdescriptionを付けたうえで、新しいempty working copyを作る。

この違いをGit commandの別名として覚えると混乱する。Jujutsuでは『今のchangeを育て、必要な位置へ置き、最後にbookmarkをpushする』と考える。GitHubへ見えるのはGit commitとbranchなので、local modelとremote protocolを分けて理解する。

既存Git repositoryをcolocateして検証した

2026年9月17日、macOS x86_64の一時directoryへJujutsu 0.45.1の公式release binaryを配置した。sample Git repositoryにinitial commitを作り、jj git init --colocate .を実行した。.gitを残したまま.jjが作られ、既存のmainとcommitがimportされた。

READMEを編集するとjj stが変更を認識し、jj diff --statは2行追加を表示した。jj describeで現在のchangeへ説明を付け、jj newで次のempty changeを作成したあと、jj undoで直前のnew操作を取り消せた。なおGit側へuser.nameとemailを設定していても、Jujutsuは作者情報が未設定だと警告した。jj config側の設定が別途必要になる点は導入時に確認したい。

sandbox repositoryで基本loopを覚える

本番repositoryへいきなり導入せず、cloneまたは一時repoでjj st、jj diff、jj describe、jj new、jj logを触る。Jujutsuではfile editが現在のchangeへ入るため、作業を始める前にjj new mainなどで目的のbaseから新しいchangeを作る習慣が重要になる。

jj undoは直前のJujutsu operationを戻す。何が戻るかを確認せず連打しない。jj op logでoperation履歴を見て、対象を理解してから復旧する。外部Git toolによる変更もcolocated workspaceへ同期されるが、同時操作や自動toolの前提を小さなrepoで確認する。

cd sandbox-repo
jj git init --colocate .
jj new main
# filesを編集
jj st
jj diff
jj describe -m 'refactor parser'
jj new
jj log

# 直前のJujutsu操作を確認して戻す
jj op log
jj undo

GitHubへ送るときだけbookmarkが必要になる

localではbookmarkなしでchange stackを作れる。GitHubへpushするときは、Jujutsuに自動名を作らせて特定changeをpushするか、named bookmarkを作ってtrackし、pushする。公式guideはworking-copy commitがemptyの場合、そのparentへbookmarkを置く例を示す。

bookmarkはGitのbranchとしてremoteへ現れるが、新しいcommitを作っても自動追従しない。review修正を追加したら、bookmarkを新しいrevisionへmoveして再pushする。Gitの『現在branchがcommitと一緒に進む』感覚を持ち込まない。

jj new main
# 変更1
jj commit -m 'refactor parser'
# 変更2
jj commit -m 'add parser tests'

jj bookmark create parser-work -r @-
jj bookmark track parser-work
jj git push --bookmark parser-work

fetchとrebaseは二段階

公式guideでは、現在git pullの直接対応commandはなく、jj git fetchでremote更新を取得し、jj rebase -o mainで自分のchangeを新しいmainへ移す。複数のbranch stackがあるなら、対象を明示してrebaseする。自動で全部が正しいbaseへ移ると仮定しない。

conflictはJujutsu内でfirst-classな状態として扱われ、解決を後へ持ち越せる。ただし、conflictを含むrevisionをbuildやpushしてよいとは限らない。CIへ送る前にjj stとjj logでconflictとbookmark位置を確認し、testを実行する。

jj git fetch
jj log -r 'main@origin..@'
jj rebase -o main
jj st
# projectのlint・test・buildを実行

colocated運用は、互換性と二重管理のtradeoff

colocated workspaceでは、各jj commandがJujutsuとunderlying Gitのviewを同期する。既存IDEやGitHub clientを残して段階移行できる利点がある。一方、Git toolがHEADやbranchを動かし、jjが再importするため、両者のmodelを理解しないまま交互に操作すると驚きが増える。

team全員がJujutsuへ移る必要はないが、repositoryのdocumentationには、bookmarkのpush方法、author設定、CI前check、問題時の復旧手順を書く。server側はGitのため、branch protectionやpull request policyは引き続きGitHub側で効く。localで履歴編集しやすいことと、remoteへforce updateしてよいことは別だ。

誰に向き、誰にはまだ早いか

複数changeのstack、頻繁なrebase、途中作業の整理、履歴編集のやり直しが多い開発者には価値がある。operation logとchange IDは、local historyを積極的に整えるworkflowと相性がよい。GitHubはそのまま使えるため、個人から試しやすい。

一方、Gitのbranch・indexを前提にした社内script、GUI、教育、hookが多い組織では移行costがある。Gitに困っていない小規模teamへ、新しい用語を増やすだけになる可能性もある。まず非重要repositoryをcolocateし、二週間程度、復旧時間とreviewのしやすさを記録して判断する。

• 本番repoではなくsandbox cloneで操作模型を覚える
• Git identityとは別にjjのuser.name・emailを確認する
• push前にbookmark位置と対象revisionを確認する
• jj op logを見てからundoや復旧を行う
• localの柔軟さとremote policyを混同しない