AI 生成聲明： 本文初稿由 Gemini AI 2.5 Flash 模型 生成, 再由個人手動修改而成。

從 Git 修訂工具到 Jujutsu 的優雅進化

你有沒有對 Git 又愛又恨過？它實在是強大, 但某些操作（特別是修改歷史、或是管理一串互相依賴的變更時）卻複雜到讓人頭痛, 像 git rebase -i 這種指令既是利器, 也常常是困擾的源頭。我想用過的人應該都懂這種感覺吧。

這篇就來聊聊一個我覺得更優雅、更直覺的選擇：Jujutsu (jj)。它並不是要取代 Git, 而是建立在 Git 基礎上的一個現代化前端, 但帶來的工作流程體驗真的差很多。

第一階段：Git 生態系統的修補與嘗試

其實在 Jujutsu 出現之前, 就已經有不少工具試著修補 Git 在「改歷史」上的痛點囉。這些嘗試, 多少都為 jj 的核心設計鋪了路。

痛點一：修訂歷史的麻煩 - git-revise 的出現

• 問題： 在 Git 裡要改一個比較舊的 commit, 你得先 git rebase -i, 找到那一行, 把 pick 改成 edit, 改完再 git commit --amend, 最後還要 git rebase --continue。光是打這串就覺得累了, 而且一不小心就會出錯。
• 解決方案的萌芽： 像 git-revise 這樣的工具, 就讓修訂一個舊 commit 簡單多了, 通常一個指令就搞定, 中斷和繼續的步驟它自己會處理。它至少證明了「改歷史是可以更簡單的」。

痛點二：依賴變更的管理 - git-branchstack 的概念

• 問題： 當你為了一個功能疊了好幾個互相依賴的 commits, 結果發現底層那個重構的 commit 需要改, 後面所有 commits 就得手動一個個 rebase, 還可能要把同樣的衝突解決好幾遍。光想就頭痛吧。
• 解決方案的探索： git-branchstack 這類工具就想出了「堆疊式分支」的概念, 讓你能更清楚地追蹤和操作一串相互依賴的變更。我想這也反映了大家對「自動幫我處理變基」這件事有多渴望。

第二階段：Jujutsu 的誕生與核心概念

Jujutsu 可以說是把這些工具累積下來的經驗跟願景, 通通吸收進一個全新的版本控制介面裡。它重新定義了幾個核心概念, 我們一個個來看：

核心概念一：工作區即提交 (Working Copy is a Commit)

• 跟暫存區 (Staging Area) 說再見： 在 jj 裡, 你的工作目錄狀態永遠就是一個提交（commit）。你改了哪些檔案, 它自動就算進當前這個提交。
  • 好處： 不用再 git add 了, 連 git stash 這個概念也消失了。一開始會有點不習慣, 但用久了真的回不去。

核心概念二：不變的「變更 ID」 (Change ID)

• Git 的問題： 在 Git 裡, 你只要動了一個舊提交（不管是 amend 還是 rebase）, 就會生出一個全新的 Commit ID (SHA-1 hash), 原本那個就消失在歷史裡了。
• Jujutsu 的解決： jj 會幫每個邏輯變更（Change）配一個不會變的 Change ID。當你修訂一個 commit 時, 它的 Commit ID 確實會變, 但 Change ID 始終如一。
  • 好處： 這讓 jj 在底層追得到變更的演進, 就算歷史被重寫, 同一個邏輯變更還是找得回來。

核心概念三：自動、安全且強大的變基 (Automatic Rebasing)

• 終結對 rebase 的恐懼： 我想這才是 jj 真正的殺手鐧。當你改了歷史中的某個提交, 所有依賴它的後續提交會自動而且安全地跟著變基, 你完全不用管。
  • 例如： 你用 jj edit <old-commit-id> 改了一個底層提交, 後面那些 commits 就會像「柔術」一樣, 優雅又自動地落到新修訂的提交之上。第一次看到的時候真是頗驚艷。

第三階段：Jujutsu 帶來的工作流程變革

jj 的指令設計更直覺、也更以「變更」為中心, 日常操作真的簡化了不少。下面這張表大概對照一下你就懂了：

結語：版本控制的未來已來

Jujutsu 把版本控制裡那些惱人的複雜度都藏了起來, 給你一個更直覺、更安全、也更貼近人腦思考方式的介面。當年 git-revise 和 git-branchstack 想各自解決的那些局部痛點, 在這裡幾乎被一次打包處理掉了。

當然啦, 我不建議你看完這篇就盲目地把 Git 全換掉——畢竟它底層還是 Git, 兩邊可以共存, 慢慢試水溫就好。不過如果你跟我一樣, 早就受夠了 Git 那套繁瑣的改歷史流程, 想要更流暢、更少踩雷的開發體驗, 那或許真的是時候來練練這門版本控制的「柔術」了 :-)