Gitの複雑さに疲れた？次世代バージョン管理「Jujutsu」で開発体験を劇的に変えよう

Gitの操作にうんざりしていませんか？「Git Rigour Fatigue（Gitの厳密な運用に対する疲弊）」を感じているなら、新しいバージョン管理システム「Jujutsu (jj)」を試すべきです。JujutsuはGoogleで開発されているツールで、Gitリポジトリとの高い互換性を持ちつつ、Git特有の複雑で直感的ではないコマンド体系を大幅に改善しています。強力なアトミック操作や、柔軟なリベース機能など、エンジニアのメンタルコストを最小限に抑える設計が魅力です。Gitの複雑なコマンドに頭を悩ませる日々にサヨナラして、開発の生産性を向上させましょう。

なぜみんながjujutsuをいいと思うのかよくわからない。しばらく使ってみたけど、同じリポジトリで多くの人と作業している身としては、コミットに合わせて追従してくれる扱いやすい名前付きブランチが必要なんだ。Gitには多くの問題があるけれど、ブランチに関してはめちゃくちゃ簡単だよね。それが当時のsvnに対する大きなイノベーションだったわけだし。

最後にjjを試した時は、ブランチを最新の状態に保つのがものすごく手間のかかる作業だった。一人で作業している人以外、どうやってこれで仕事してるのか謎だよ。自分も同僚も、常にいくつものブランチを並行して動かしているから、手動で正しいコミットを指し続けるなんて考えられないよ。

もしその驚くような仕様が修正されているなら、もう一度試してもいいけどね。現状ではブランチとworktreesが私のやり方だよ。

記事の内容については、赤緑色盲なので何が起きているのか全くわからない。

absorb は直近でそのファイルを触ったコミットに基づいて変更を割り当てるけれど、それが必ずしも変更の帰属先として正しいとは限らない。

jj absorb（それに先行する git-absorb 0 や hg absorb）は、もっと賢く実際のdiffを見て判断しているはずだよ。

Magitの専門家というわけじゃないけど、たった数回のキー入力で同じことができる方法があると思うよ。

git rebaseを愛用していた者として、完全にjujutsuに乗り換えたよ。全体的な体験がより人間工学に基づいていると思う。私が使っているデフォルトのワークフロー（作業を始める前に jj new で別の「作業」であることを明確に区別した新しい変更を作成する）は、我々が慣れ親しんだ従来の「書いてからコミットする」ワークフローよりも、ずっとしっくりくる。

jujutsuへの乗り換えをためらっている唯一の理由は、lazygitがこれら細かい不便さをかなり上手く解消してくれているからかな。特にカスタムパッチ機能が使えなくなるのは痛い。

JJ向けにも似たようなプロジェクトがあるみたいだけど、まだ全然洗練されてなさそう。 https://github.com/Cretezy/lazyjj (https://github.com/Cretezy/lazyjj)

これは「理想化されたコミットの連なり」と「その上の作業用コミット」を維持する、jjのより自然なワークフローと比べるとかなり手間がかかるように見える。調整や修正をしたら、関係する部分をすでに綺麗な履歴の中にsquash（統合）していくだけだしね。

要するに、そもそもコミットに混ぜるべきでないものが混ざるような状況に陥らなければ、履歴を整理するための余計な作業は一切不要ってこと。ブランチの先端だけが「散らかって」いる状態にすればいいんだ。

これは jj megamerge を思い出すな。jjならVCSのことは気にせずに開発に集中できるし、最初にVCS特有の問題（コンフリクト）を解決（megamerge）することもできる。本当によくできてるよ。

ついにPRのsquashを全面的に受け入れることにしたよ。良いコミットを書こうとして若さを無駄にしていたことに気づいた。

後のコミットが以前のコミットで行った作業を上書きしてしまい、話の筋が壊れてしまう。

これを好む人もいる。git bisectが上手く機能しやすくなるからね。デバッグのしやすさとレビュアーの利便性のトレードオフってことか。

理想を言えば、ある目的のために「起きたままの履歴」を保存しつつ、別の目的のために「綺麗にsquashしてrebaseされた履歴」も保存し、それらが確実に一致するように管理できるVCSがあれば最高なんだけどね。

意味がわからないな。「git rebase -i」を一度も使わずにgitを使おうとする人が本当にいるの？