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

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

許多資深開發者都對 Git 的強大功能愛恨交織。它強大, 但某些操作（特別是修改歷史和管理一系列依賴的變更時）卻異常複雜, 像是 git rebase -i 這樣的指令既是利器, 也常是困擾的源頭。

我們將探討一種更優雅、更直覺的版本控制解決方案：Jujutsu (jj)。它並不是要取代 Git, 而是作為一個建立在 Git 基礎上的現代化前端, 帶來革命性的工作流程。

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

在 Jujutsu 誕生之前, 許多工具試圖修補 Git 的「歷史修改」痛點。這些嘗試為 jj 的核心設計奠定了基礎。

問題： 在 Git 中修改一個比較舊的 commit, 你需要用 git rebase -i, 找到那一行, 將 pick 改成 edit, 修改後再 git commit --amend, 最後 git rebase --continue。過程繁瑣且容易出錯。
解決方案的萌芽： 像 git-revise 這樣的工具, 讓修訂一個舊 commit 變得更簡單, 通常只需一個指令, 就能自動處理中斷和繼續的步驟。它證明了「歷史修訂可以更簡單」的可能性。

問題： 當你在一個功能上提交了多個依賴的 commits, 如果底層重構的 commit 需要修改, 後續所有 commits 都需要手動 rebase, 或者面對重複的衝突解決。
解決方案的探索： git-branchstack 等工具, 嘗試建立一個「堆疊式分支」的概念, 讓開發者能更清楚地追蹤和操作一系列相互依賴的變更。這突顯了開發者對「自動化處理變基」的渴望。

Jujutsu 正是吸收了這些工具的經驗和願景, 將其融入一個全新的版本控制系統介面中。它重新定義了幾個核心概念：

告別暫存區 (Staging Area)： 在 jj 中, 你的工作目錄狀態永遠是一個提交（commit）。你對檔案的修改會自動被視為對當前工作提交的修改。
- 好處： 不再需要 git add, 也沒有 git stash 的概念。

Git 的問題： 在 Git 中, 你修改一個舊提交（例如使用 amend 或 rebase）會產生一個全新的 Commit ID (SHA-1 hash)。
Jujutsu 的解決： jj 為每個邏輯變更（Change）分配一個不變的 Change ID。當你修訂一個 commit 時, 它的 Commit ID 會改變, 但 Change ID 保持不變。
- 好處： 讓 jj 能夠在底層追蹤變更的演進, 即使歷史被重寫, 邏輯變更仍可追溯。

終結 rebase 的恐懼： 這是 jj 的殺手鐧。當你修改歷史中的某個提交時, 所有後續依賴於它的提交會自動且安全地進行變基。
- 例如： 你使用 jj edit <old-commit-id> 修改了一個底層提交, 你後續的 commits 會像「柔術」一般優雅地、自動地移到新修訂的提交之上。

jj 的指令設計更直覺、更以「變更」為中心, 極大地簡化了日常操作。

jj 操作	傳統 Git 工作流	優勢與變革
`jj undo`	難以實現, 需要 `git reflog`	一鍵撤銷：所有操作（包括變基、修訂）都是可撤銷的, 提供了無損的工作安全網。
`jj squash`	`git rebase -i` 或 `git commit --amend`	輕鬆合併：快速將當前工作區的變更併入父提交。
`jj split`	`git rebase -i` + 手動操作	輕鬆拆分：在不修改原提交的前提下, 將其部分內容拆分為新提交。
`jj log`	`git log --graph`	清晰日誌：預設輸出更易讀的變更圖, 並顯示 Change ID。

Jujutsu 將版本控制的複雜性抽象化, 提供了更直覺、更安全、更符合人腦思考邏輯的操作介面。它將我們從 git-revise 和 git-branchstack 試圖解決的局部痛點中解放出來, 提供了一個更全面、優雅的解決方案。

如果你厭倦了 Git 繁瑣的歷史修改流程, 渴望更流暢、更少出錯的開發體驗, 那麼是時候擁抱這門版本控制的「柔術」了。