~/notes - Jujutsu

How I Keep Private Changes Clean in a Jujutsu Megamerge Workflow

2026-10-09T00:00:00+00:00

Introduction</h2>
Recently, I briefly introduced the Jujutsu Megamerge Workflow. 1</a>
In this post, I will share examples of how I handle private changes using the Megamerge Workflow. The intended readers are those who have a general understanding of the Megamerge Workflow but cannot quite imagine the specific situations where it becomes useful. If you want to learn more about the Megamerge Workflow, please refer to the following articles.

Jujutsu megamerges for fun and profit - Isaac Corbrey</a></li>
Jujutsu Megamerges and jj absorb - Sym·poly·mathesy</a></li>
Working on all of your branches simultaneously - Steve's Jujutsu Tutorial</a></li>
Dispatching Edits from Megamerges - Ju! Ju! Tsu!</a></li> </ul>
By using Megamerge Workflow, you can keep "messy commits in progress" or "local-only changes" while pushing only cleaned-up, organized changes to the remote. While this requires complex state management in Git, Jujutsu allows you to eliminate it entirely.
Megamerge Workflow and Private Changes</h2>
As mentioned in the previous article 1</a>, I often commit changes to the repository as "private changes" when I want them reflected in the working copy but not on the remote (or don't need them to be).
Specifically, these include Nix Flake-related files (`flake.nix</code>, flake.lock</code>) and repository-local dictionary files for` Harper</a> (.harper-dictionary</code>). Regarding flake.nix</code> and flake.lock</code>, there is a constraint on the Nix side where evaluation is not possible unless the files are in a state tracked by Git. 2</a> I often use Nix devShells to prepare the tools necessary for development. However, since other team members do not use Nix, the communication cost of introducing files that only I use into the team repository requiring them to be reviewed is too high. Therefore, I would prefer to commit these as "private changes" confined to my local environment.
`If using only Git, such changes would need to be stashed using git stash</code> before pushing. With the Megamerge Workflow, you can keep all changes in the working copy and only carve out the parts you want to push to the remote.`
`In the Megamerge Workflow, the working copy contains all of the following:`
A series of changes being stacked to be pushed to the remote</li> Private changes (commits) for flake.nix</code> and flake.lock</code></li> Private changes (commits) for .harper-dictionary</code></li> etc.</li> </ul> </figure> This way, flake.nix</code> and flake.lock</code> are always tracked by Git (Jujutsu), while being managed only in my local environment without being pushed to the remote. They are truly "private changes." When I want to reflect changes on the remote, I create a bookmark for the relevant changes as follows: </figure> Then, I simply push it using jj git push --bookmark <bookmark></code>. In this way, by creating changes intended for the remote on a branch separate from private changes, I can manage them so that private changes are not pushed. However, there is still a risk that private changes could be pushed to the remote due to operational error. jj configurations</h2> To prevent pushing private changes to the remote, git.private-commits</code> 3</a> is useful. This option takes a revset. Any changes matching this revset will be blocked from being pushed. revset-aliases</h3> To identify changes that should not be pushed to the remote, I use revset aliases. I manage the types of changes based on prefixes in the description (commit message) such as "private:", "wip:", "todo:", "mega", etc. Here, I treat changes whose description starts with "private" as private changes. To support this rule, I create a revset alias as follows: [revset-aliases] 'private()' = 'description(glob:"private")'</code></pre> Evaluating private()</code> lists only the changes with descriptions starting with "private", as intended. </figure> In addition to private changes (private</code>), I also define wip</code> (work in progress), todo</code> (incomplete), and mega</code> (formal changes for Megamerge) as revset aliases. [revset-aliases] 'wip()' = 'description(glob:"wip")' 'todo()' = 'description(glob:"todo")' 'private()' = 'description(glob:"private")' 'mega()' = 'description(glob:"mega*")' 'local()' = 'wip() | todo() | private() | mega()'</code></pre> I also define a local()</code> revset alias to handle all of these together. Using this revset alias in git.private-commits</code>, it prevents the pushing of changes that match local()</code> and their descendants. [git] private-commits = 'local()'</code></pre> While git.private-commits</code> is a robust way to prevent accidental pushes, it only handles the "what not to push" part. Sometimes, you want to perform additional checks—such as running a linter or a test suite—immediately before the push happens. This is where a custom jj push</code> alias becomes useful. Before I discovered the git.private-commits</code> option, I relied entirely on this alias as my primary guardrail. Even now, I continue to use it to integrate tools like pre-commit into my workflow. jj push alias</h2> In the Jujutsu configuration file, you can set aliases 4</a>. You can assign jj</code> subcommands and arguments to any alias. Additionally, using the jj util exec</code> subcommand 5</a>, you can execute arbitrary external commands via jj</code>. By combining these, I created a jj push</code> alias for pushing to the remote. The functionality of jj push</code> is as follows: Verify that changes that should not be pushed to the remote are not included in the push target</li> Run pre-commit</code> before pushing</li> Execute jj git push</code> to push changes to the remote</li> </ul> One minor drawback of Jujutsu is that it doesn't natively support Git hooks, such as pre-commit</a>. Therefore, I have configured pre-commit</code> to run within the jj push</code> alias. Essentially, it's no longer a "Pre commit" but rather a "Pre push" check. I've set it up so that if the pre-commit</code> command fails, the push is stopped; otherwise, the push proceeds. </figure> jj push Alias Example</h3> Based on the above, I have configured the jj push</code> alias as follows: https://github.com/rinx/dotfiles/blob/d1033370a8cb2142a2c506d3131da5cb28633f6d/jjconfig.toml#L45-L81</a> [aliases] push = [ 'util', 'exec', '--', 'bash', '-c', ''' ## Run check if pre-commit is available if type pre-commit >/dev/null 2>&1; then echo "==> Running pre-commit before push..." pre-commit run --all-files if [ $? -ne 0 ]; then echo "❌ pre-commit failed. Aborting push." exit 1 fi else echo "⚠️ pre-commit not found. Skipping checks." fi ## Extract the target Revset from command line arguments. Use default `::@` if not specified echo "==> Checking for forbidden markers in pushable commits..." targets=$(echo "$@" | grep -oP '(?<=(-b|--bookmark|-c|--change|-r|--revision)\s)[^ ]+') if [ -z "$targets" ]; then target_revset="::@" else target_revset="::(${targets//$'\n'/|})" fi ## Verify that no unintended changes are included in the push target if [ -n "$(jj log -r "$target_revset & mutable() & local()" --no-graph --ignore-working-copy -T 'commit_id')" ]; then echo "❌ Commits to be pushed contain wip/todo/private/mega markers. Aborting push." exit 1 fi ## Execute push to remote echo "==> Pushing changes to remote..." echo "==> jj git push $@" jj git push $@ ''', '', ]</code></pre> By preparing simple guardrails as aliases, you can use Jujutsu with more peace of mind. I encourage you to build the optimal workflow and aliases that suit your own usage. This article was translated with AI assistance and reviewed by the author. ^1Jujutsu を用いた開発ワークフロー: Squash Workflow と Megamerge Workflow</a> </div> ^2GitとFlake - Nix入門: ハンズオン編</a> </div> ^3Set of private commits - Jujutsu docs</a> </div> ^4Aliases - Jujutsu docs</a> </div> ^5jj util exec</a> </div>



Jujutsu Megamerge でプライベートな変更をリモートにプッシュしないようにする
2026-10-06T00:00:00+00:00
English translation</a> is available.</p>
はじめに</h2>
先日は Jujutsu の Megamerge Workflow を簡単に紹介した。 1</a></sup></p>
そこではプライベートな変更を管理する例を取り上げたが、今回はそれをどのように Megamerge Workflow と組み合わせているかの具体例を紹介したい。
Megamerge Workflow がどのようなものかはある程度理解しているが、どのようなシチュエーションで便利なのかがイメージできていない人が想定読者だ。
Megamerge Workflow について詳しく知りたい方はまず Jujutsu を用いた開発ワークフロー: Squash Workflow と Megamerge Workflow</a>1</a></sup> や記事中のリンク先を参考にしていただきたい。</p>
Megamerge Workflow を導入することで「作業中の汚いコミット」や「ローカル専用の変更」を保持したまま、リモートには整理されたキレイな変更だけをプッシュすることができるようになる。
Git では複雑な状態管理が必要になる一方、 Jujutsu を用いればこの煩雑さを一気になくすことができる。</p>
Megamerge Workflow とプライベートな変更</h2>
先日の記事 1</a></sup> でも触れたように、私はよく「ワーキングコピーには反映しておきたいが、リモートには反映したくない(しなくてもいい)変更」を「プライベートな変更」としてリポジトリにコミットすることがある。</p>
具体的には Nix の Flake 関連ファイル (flake.nix</code>, flake.lock</code>) や Harper</a> のリポジトリローカルな辞書ファイル (.harper-dictionary</code>) だ。
特に flake.nix</code>, flake.lock</code> に関しては Git で追跡されている状態でないと評価ができないという Nix 側の制約がある。 2</a></sup>
私は開発に必要なツールを Nix の devShell で用意することが多い。
一方、他のチームメンバーは Nix を利用していないため、自分しか利用しないファイルをわざわざレビューしてもらってまでチームのリポジトリに導入するのはコミュニケーションコストが高すぎる。
そのため、これらを「プライベートな変更」としてローカル環境に閉じてコミットしておけるとうれしい。</p>
Git のみを利用している場合、このような変更はプッシュ前に git stash</code> で退避させるなどの必要がある。
Megamerge Workflow を用いれば、すべての変更をワーキングコピー上に残したまま、プッシュしたい部分だけを切り出してリモートへプッシュできる。</p>
Megamerge Workflow では、ワーキングコピーは次のような変更がすべて含まれた状態となる。</p>

リモートにプッシュする変更を積んでいくための変更群</li>
flake.nix</code>, flake.lock</code> のプライベートな変更(コミット)</li>
.harper-dictionary</code> のプライベートな変更(コミット)</li>
etc..</li>
</ul>

  
  
</figure>
これなら flake.nix</code>, flake.lock</code> は常に Git (Jujutsu) で追跡されている状態となるし、一方でリモートにプッシュせずに自分の手元の環境だけで管理しておける。まさに「プライベートな変更」と言える。</p>
変更をリモートに反映したいときは、次のようにして該当する変更に bookmark を作成する。</p>

  
  
</figure>
あとはこれを jj git push --bookmark <bookmark></code> でプッシュすれば良い。
このように、リモートに反映したい変更はプライベートな変更とは別のブランチ上に作成していくことで、プライベートな変更がリモートにプッシュされないように管理する。
しかし、これだけでは操作を誤ってプライベートな変更をリモートにプッシュしてしまう可能性が依然残る。</p>
jj push エイリアス</h2>
Jujutsu の設定ファイルではエイリアス 3</a></sup> を設定できる。任意のエイリアスに jj</code> のサブコマンドと引数を割り当てられる。
また、 jj util exec</code> サブコマンド 4</a></sup> を用いると任意の外部コマンドを jj</code> 経由で実行できる。
これらを組み合わせて、 リモートへのプッシュ用に jj push</code> エイリアスを作成する。</p>
jj push</code> の機能は次のとおり。</p>

リモートにプッシュしたくない変更がプッシュ対象に含まれないことを確認する</li>
jj git push</code> を実行して変更をリモートにプッシュ</li>
</ul>
jj git push</code> の代わりに jj push</code> エイリアスを利用するようにすれば、操作を誤ったとしてもプライベートな変更をリモートにプッシュすることがないようにできる。
誤って Megamerge のマージコミットをリモートにプッシュしようとすると、次のようにエラーで弾かれる。</p>

  
  
</figure>
revset-aliases</h3>
リモートにプッシュしたくない変更を識別するため、 revset aliases を利用する。</p>
私は、変更の Description (コミットメッセージ) の接頭辞 ("private:", "wip:", "todo:", "mega" など) により変更の種類を管理するようにしている。
ここでも、変更の Description が "private" からはじまるものをプライベートな変更として扱うことにする。このルールに対応するように、次のとおりに revset alias を作成する。</p>
[</span>revset-aliases</span>]</span></span>
'private()'</span> =</span> 'description(glob:"private*")'</span></span></code></pre>
private()</code> を参照すると、意図したとおり "private" からはじまる Description を持つ変更のみがリストアップされる。</p>

  
  
</figure>
ここでは、プライベートな変更 (private</code>) 以外にも wip</code> (作業中), todo</code> (未完了), mega</code> (Megamerge 用の形式的な変更) も revset aliases として定義しておく。</p>
[</span>revset-aliases</span>]</span></span>
'wip()'</span> =</span> 'description(glob:"wip*")'</span></span>
'todo()'</span> =</span> 'description(glob:"todo*")'</span></span>
'private()'</span> =</span> 'description(glob:"private*")'</span></span>
'mega()'</span> =</span> 'description(glob:"mega*")'</span></span>
'local()'</span> =</span> 'wip() | todo() | private() | mega()'</span></span></code></pre>
これらにあてはまるものをまとめて扱えるように local()</code> という revset alias も定義しておく。</p>
jj log -r "$target_revset & mutable() & local()"</code> のようにプッシュ対象の revset と組み合わせて jj log</code> コマンドを実行すると、「プッシュ対象」かつ「未プッシュの変更 (mutable()</code>)」 (リモートにプッシュ済みの変更はチェック対象外とする) かつ「 local()</code> に該当」する変更のみを抽出できる。
この実行結果が空であれば local()</code> に該当する変更がプッシュ対象に含まれていないと確認できる。</p>
pre-commit</h3>
Jujutsu を利用する上で少し困るのが、 pre-commit</a> をはじめとした Git hooks をうまく扱えないことだ。
そこで私は、 jj push</code> エイリアスの中で pre-commit</code> を実行するように設定しているので、これもついでに紹介しておく。</p>
本質的には "Pre commit" ではなくなってしまうが、 "Pre push" なチェックとして pre-commit</code> ツールを実行するようにしている。
pre-commit</code> コマンドの実行結果が失敗ならプッシュを止め、成功ならプッシュを実行するようにしておく。</p>

  
  
</figure>
jj push エイリアス例</h3>
以上の内容を踏まえて、私は jj push</code> エイリアスを次のように設定している。</p>
https://github.com/rinx/dotfiles/blob/d1033370a8cb2142a2c506d3131da5cb28633f6d/jjconfig.toml#L45-L81</a></p>
[</span>aliases</span>]</span></span>
push</span> =</span> [</span></span>
  'util'</span>,</span></span>
  'exec'</span>,</span></span>
  '--'</span>,</span></span>
  'bash'</span>,</span></span>
  '-c'</span>,</span></span>
  '''</span></span>
## pre-commit が利用できるときはチェックを実行</span></span>
if type pre-commit >/dev/null 2>&1; then</span></span>
    echo "==> Running pre-commit before push..."</span></span>
    pre-commit run --all-files</span></span>
</span>
    if [ $? -ne 0 ]; then</span></span>
        echo "❌ pre-commit failed. Aborting push."</span></span>
        exit 1</span></span>
    fi</span></span>
else</span></span>
    echo "⚠️  pre-commit not found. Skipping checks."</span></span>
fi</span></span>
</span>
## コマンドライン引数からプッシュ対象の Revset を抽出。指定されていないときはデフォルトプッシュ対象の `::@` を使用</span></span>
echo "==> Checking for forbidden markers in pushable commits..."</span></span>
targets=$(echo "$@" | grep -oP '(?<=(-b|--bookmark|-c|--change|-r|--revision)\s)[^ ]+')</span></span>
if [ -z "$targets" ]; then</span></span>
  target_revset="::@"</span></span>
else</span></span>
  target_revset="::(${targets//$'\n'/|})"</span></span>
fi</span></span>
## プッシュ対象に意図しない変更が含まれないかを確認</span></span>
if [ -n "$(jj log -r "$target_revset & mutable() & local()" --no-graph --ignore-working-copy -T 'commit_id')" ]; then</span></span>
    echo "❌ Commits to be pushed contain wip/todo/private/mega markers. Aborting push."</span></span>
    exit 1</span></span>
fi</span></span>
</span>
## リモートへのプッシュを実行</span></span>
echo "==> Pushing changes to remote..."</span></span>
echo "==> jj git push $@"</span></span>
jj git push $@</span></span>
'''</span>,</span></span>
  ''</span>,</span></span>
]</span></span></code></pre>
エイリアスとして簡単なガードレールを用意することで、より安心して Jujutsu を利用することができるようになる。
自身の使い方に合わせて最適なワークフローやエイリアスを構築してみてほしい。</p>
追記</h2>
この記事を公開した後に気付いたが、 Jujutsu 自体に git.private-commits</code> 5</a></sup> という設定項目があった。
「プライベートな変更をリモートにプッシュしないようにする」という目的のためには、公式に用意されたこの仕組みを利用する方が筋が良い。
本稿の設定例にあわせて書くと、次のようになる。</p>
[</span>git</span>]</span></span>
private-commits</span> =</span> 'local()'</span></span></code></pre>
これにより、 local()</code> に該当する変更とその子孫にあたる変更のプッシュを防止できる。</p>
jj push</code> エイリアス方式は pre-commit のようにプッシュ操作にフックして何かしらのチェックを実施したい場合には依然有効なので、これはこれで残しておこうと思う。</p>
^1</sup>Jujutsu を用いた開発ワークフロー: Squash Workflow と Megamerge Workflow</a></p>
</div>
^2</sup>GitとFlake - Nix入門: ハンズオン編</a></p>
</div>
^3</sup>Aliases - Jujutsu docs</a></p>
</div>
^4</sup>jj util exec</a></p>
</div>
^5</sup>Set of private commits - Jujutsu docs</a></p>
</div>


Jujutsu を用いた開発ワークフロー: Squash Workflow と Megamerge Workflow
2026-09-22T00:00:00+00:00
業務を含めた開発フロー全般で Jujutsu (jj-vcs/jj, jj</code>)</a> を使うようになってからもうすぐ半年になる。
現在の個人的な jj</code> 利用ワークフローと、 jj</code> について便利だと感じている部分をまとめておこうと思う。</p>
Jujutsu について</h2>
あらためて紹介する必要もないが、 jj</code> は Git 互換のバージョン管理システムだ。</p>

jj-vcs/jj</a></li>
Jujutsu docs</a></li>
</ul>
Git でできることのほとんどは jj</code> でもできる。 jj</code> でできることも大抵は Git でできる。
しかし、同じことをやろうとしても jj</code> のほうが圧倒的に簡単にできる場合が多い。</p>
たとえば、過去の特定のコミットだけを修正したいときに Git なら git rebase -i</code> を利用し、該当のコミットに edit</code> フラグを立てて編集モードに入り…と複雑な手順を踏む必要があるが、 jj</code> の場合は jj edit <rev></code> で該当の変更を選択し、ファイルを編集するだけで簡単に修正できる。</p>
Rebase 操作を例にとっても、 jj rebase --before <before> --after <after> --revision <rev></code> のように、どの変更をどの位置に Rebase するかが直感的にわかる形で操作ができる。</p>
それらに加えて jj undo</code>, jj redo</code> により操作の Undo / Redo ができるため、変更履歴の操作を行うことへのハードルが非常に低い。
この操作感に慣れてしまうと、もう素の Git に戻る気はなくなってしまう。</p>
jj</code> そのものの紹介は既にさまざまなリソースがあるので、ここでは参考文献を紹介するだけにとどめておく。</p>

Steve's Jujutsu Tutorial</a></li>
Ju! Ju! Tsu!</a></li>
君のレポジトリを領域展開 - 次世代バージョン管理システム Jujutsu (jj-vcs/jj)の世界</a></li>
</ul>
Squash Workflow</h2>
jj</code> を用いたワークフローの中でも特に Git ユーザーにとって馴染みやすいのが Squash Workflow だ。
私も基本的にはこのワークフローに則って作業をしている。</p>
Git ではコミットに含めたい変更内容を index にステージング (git add</code>) してからコミット (git commit</code>) するが、 jj</code> の Squash Workflow ではワーキングコピーにある変更内容を jj squash</code> により過去の変更に移動させる。 jj</code> には Git の index に対応するエリアはないが、このワークフローにおいてはワーキングコピーにある変更がステージングされた変更に該当すると捉えると理解しやすい。</p>
このワークフローについては次のページの解説がわかりやすい。</p>

The Squash Workflow - Steve's Jujutsu Tutorial</a></li>
The Squash Workflow - Ju! Ju! Tsu!</a></li>
</ul>
冒頭で過去のコミットの修正を jj edit <rev></code> で行う例を挙げたが、 Squash Workflow を用いると次のようになる。</p>

jj new <rev></code> で修正したい変更から新しい変更を作成する</li>
修正内容をワーキングコピーに反映する</li>
jj squash</code> により、ワーキングコピーの変更を元の <rev></code> に移動させる</li>
</ul>
対象の変更に直接 jj edit</code> を実行するよりも、このように Squash Workflow を用いたほうが、元の変更に対してどのような修正をしたかを確認してから反映できるため好ましい。
このあたりは Don’t Edit - Ju! Ju! Tsu!</a> で解説されている。</p>
Megamerge Workflow</h2>
このワークフローは、ある意味では Squash Workflow の派生版とも言える。
詳しくは参考ページを読んでもらえると良いが、同じリポジトリ上で複数の作業を行うとき、ブランチを切り替える必要なく同じワーキングコピー上ですべての変更を行うことができる。</p>

Jujutsu megamerges for fun and profit - Isaac Corbrey</a></li>
Jujutsu Megamerges and jj absorb - Sym·poly·mathesy</a></li>
Working on all of your branches simultaneously - Steve's Jujutsu Tutorial</a></li>
Dispatching Edits from Megamerges - Ju! Ju! Tsu!</a></li>
</ul>
モノリポ構成で複数のコンポーネントに対する変更を並行で進める場合などは特にこのワークフローにフィットする。私も業務で触るリポジトリはだいたいこのパターンにあてはまるため、このワークフローをよく利用している。
たとえば、次のような変更を積んだリポジトリを考えてみる。</p>

  
  
</figure>
変更グラフのすぐ右に表示されている8桁の文字列が Change-ID (変更ID) を表している。 Change-ID は太字になっている部分まででユニークに扱われる。
この例では、 ID が r</code> の変更から4つの変更 (u</code>, v</code>, sx</code>, sr</code>) に派生して、それらを n</code> でマージ (megamerge) している。</p>
この仮想リポジトリでは、 Server 側の変更と Client 側の変更をローカル環境で同期させながら、リモート側には別ブランチとして Push してそれぞれ別の Pull Request として変更を提出することを想定している。
また、他メンバーに共有する必要のない flake.nix</code>, flake.lock</code> や .harper-dictionary</code> を含む変更を Private な変更として扱い、リモートには Push しない方針としている。 (私の場合チームメンバーで Nix や Harper を利用している人はいないので、手元に置いておけば十分)
jj</code> にはブランチがなく、代わりにコミットに対するブックマーク (bookmark) を指定するようになっている。そのため、 sx</code>, sr</code> のみに bookmark を指定して Push することで、リモートには不要な変更を Push せずに済む。</p>
各ブランチに変更を加えたいときは、Squash Workflow と同じくワーキングコピー上で変更内容を作成し、 jj squash</code> で該当する変更に移動させれば良い。
さらに、 jj squash</code> の代わりに jj absorb</code> を利用すれば、多くの場合で変更内容を自動的に適切な変更に Squash してくれる。先の例では、 .harper-dictionary</code> に関する変更や flake.nix</code> に関する変更がワーキングコピーに一緒に含まれていたとしても、 jj absorb</code> を実行するだけで自動的に v</code> や u</code> の変更に取り込んでくれる。編集しているファイルや編集箇所をもとに適切な取り込み先を判別しているのだ。 Megamerge Workflow を利用する際はこれが非常に便利なので、覚えておくと良い。</p>

~/notes - Jujutsu

How I Keep Private Changes Clean in a Jujutsu Megamerge Workflow

jj push Alias Example</h3> Based on the above, I have configured the jj push</code> alias as follows:</p>

Jujutsu Megamerge でプライベートな変更をリモートにプッシュしないようにする

jj push エイリアス例</h3> 以上の内容を踏まえて、私は jj push</code> エイリアスを次のように設定している。</p>

Jujutsu を用いた開発ワークフロー: Squash Workflow と Megamerge Workflow