STORES Product Blog

こだわりを持ったお商売を支える「STORES」のテクノロジー部門のメンバーによるブログです。

Gitの代わりにJujutsuを使い始めて1ヶ月

この記事はSTORES Advent Calendar 2025の9日目の記事です。

こんにちは。Webエンジニアをしているotariidaeです。呪術廻戦は未履修です。

個人的にgitコマンドの代わりにJujutsu(jjコマンド)を使い始めてから1ヶ月ほどが経ちました。 この記事では実際に業務で毎日使ってみてどうだったかをふりかえってみようと思います。

Jujutsuとは

Jujutsuは比較的新しいバージョン管理システムです。Gitをバックエンドとして利用できるため、既存のGitリポジトリで自分だけしれっと使い始められます。

# 既存リポジトリで使い始めるにはこのコマンド打つだけ
jj git init

典型的なワークフローは次の公式ドキュメントに記載されています。

Working with GitHub - Jujutsu docs

Gitとの違いとして最初に気づくのは、ステージングエリアがない点ではないでしょうか。作業がコミットに直結しており、ファイルを編集すると“ワーキングコピー”というところに自動的にコミットされていきます。

そんなことをしたらコミットログがはちゃめちゃになるように思いますが、Jujutsuは代わりに“チェンジ”という単位で歴史を刻みます。チェンジは論理的な変更意図の単位というイメージで、ファイルが変更されてコミットが変わったとしてもチェンジは同じままになります。

詳しくは次の公式ドキュメントに記載されています。

Working copy - Jujutsu docs

便利ポイント

Jujutsuを業務で常用するなかで便利だと感じた点を3つピックアップしてご紹介します。

1. 歴史の編集が楽

Gitで過去の歴史を編集するのは結構めんどうだと思うことがたびたびありました。直前のコミットにまとめるだけであれば git commit --amend --no-edit で済みますが、それ以上前のコミットを編集するのであれば git rebase -i でeditマークを付けて...という手順が必要です。なにもわからなくなって git rebase --abort することもありました。

Jujutsuは上述の性質により、歴史の編集に対するハードルが低いです。特定のチェンジを編集したいときは、そこから新しくチェンジを生やし、ファイル編集が終わったらスカッシュして元のチェンジにまとめるだけです。

jj new <チェンジID>
# (この間にファイル編集する)
jj squash

2. スタッシュ不要

Gitでブランチを頻繁に切り替えていると、スタッシュに手元の変更内容を退避することが多くなりがちです。スタッシュがどんどん溜まっていって復帰するときにどれがどれだかわからない🤯状態になることも少なくありませんでした。

Jujutsuはワーキングコピーをスパッと切り替えられます。これによりコンテキストスイッチのオーバーヘッドが減らせます。

# mainブランチから新しい作業を始めるときの常套句
jj new main@origin

3. ブランチ名をつけなくて良い

命名は意思決定です。小さな意思決定でもたくさんやると疲れます。

Jujutsuはpushする際にブランチ名を自動生成してくれるので、日ごろの小さな意思決定を減らせます。

# 直前のチェンジをpushする
jj git push -c @-

もちろん名前を自分でつけることもできますが、最近はもっぱら自動生成に頼りきっています。

イマイチポイント

せっかくなので悪かった点も述べておきます。

1. AIにハルシネーションされる

Jujutsuは巷に情報が乏しいためか、GeminiにJujutsuの使い方を尋ねたらたまにハルシネーションを受けました。 例えば jj rebase-r-s オプションを取り違えて説明されたせいで小一時間溶けました🫠。

横着せずに公式ドキュメントの英語を読むべし、という教訓を得ました。

まとめ

Gitとは異なるメンタルモデルが求められるため、最初はなにをするにも手こずっていましたが、2週間ほどで典型的な操作には慣れました。 今後も使い続けてもっと使いこなせるようになっていきたいです。

Gitに飽きたな、たまには味変しようかなと思っている人はJujutsuをぜひ試してみてはいかがでしょうか?

図らずも昨日の記事もバージョン管理システムの話でした。ぜひこちらもご一読ください。

product.st.inc