AI 生成聲明： 本文初稿由 Claude AI Sonnect 4.5 模型 生成, 再由個人手動修改而成。

前言：Git 工作流的痛點

用 Git 寫程式寫久了, 你一定也碰過這幾種情況吧:

  • 想改一下歷史裡的某個 commit, 就得用 git rebase -i 進互動模式
  • 手上有好幾個相關的 feature branch, 分支之間誰依賴誰, 還得自己記在腦袋裡
  • 一個手滑改錯了想回到之前的狀態, 只好靠 git reflog 來救援
  • Commit 完才發現有個檔案忘了加, 又得 git commit --amend 補一次

這些操作當然都很強大, 只是常常要記一堆命令組合, 對新手實在是不太友善。而且我覺得更要命的是, 它們會打斷你的思緒, 讓注意力從「解決問題」整個被拉去「操作工具」。

對追求順手工作流的人來說, 這些摩擦一點一滴累積起來, 其實是不容小看的時間成本。於是就有些人開始動腦筋, 想找出更貼合自己習慣的版本控制方式…

第一步：git-revise — 簡化歷史編輯

誕生背景

git-revise 的出現, 就是為了治 git rebase -i 的麻煩。對於常常要改 commit 歷史的人來說, 互動式 rebase 那一整套流程實在是太繁瑣了。git-revise 則提供了一條更直接的路, 達成同樣的目的。

核心特點

# 傳統 git rebase 的方式
git rebase -i HEAD~3  # 進入編輯器, 標記 edit/reword/squash...

# git-revise 的方式
# 1. 先修改檔案
vim some_file.py
# 2. Stage 你的修改
git add some_file.py
# 3. 應用到目標 commit
git revise <commit-hash>  # 將 staged changes 應用到該 commit

優勢

  • 更安全: 自動保留原始狀態,隨時可以恢復
  • 更直覺: 直接操作目標 commit,不需要互動式編輯器
  • 避免衝突: 智能處理 commit 間的依賴關係

限制

  • 仍然基於 Git 的 branch 模型
  • 無法徹底解決多分支管理的複雜性

第二步：git-branchstack — Branchless 工作流的個人實踐

為什麼需要它？

不少人慢慢發現, 傳統那套「一個 feature 一個 branch」的做法, 真正做起來其實頗不順手:

  • 每次切 branch 都得重新 build 一次
  • 好幾個相關的 PR, 依賴關係還是得自己手動維護
  • 在不同 branch 之間跳來跳去, 思緒一直被打斷

git-branchstack 就是一個拿來提升個人效率的小工具, 讓你能用更自然的方式做事: 所有開發都留在同一個 branch 上, 只有要送 PR 的時候才生出對應的分支。

問題場景

假設你想在同一個分支上開發好幾個功能, 每個功能各自對應一個 PR:

  • 功能 A: 重構 authentication
  • 功能 B: 新增 profile 頁面 (依賴 A)
  • 功能 C: 一個無關的 bugfix

傳統做法需要:

  1. 為每個功能建立獨立分支
  2. 在分支間來回切換
  3. 每次切換都重新 build, 浪費時間
  4. 手動管理分支間的依賴關係

git-branchstack 的創新解法

git-branchstack 的巧思, 是讓你一直待在本地分支, 改用 commit message 上的標籤來標記主題:

# 在本地分支上正常開發
git commit -m "[auth-refactor] Update login logic"
git commit -m "[auth-refactor] Add JWT support"
git commit -m "[profile-page:auth-refactor] Add profile component"
git commit -m "[bugfix-123] Fix memory leak"

# 一行命令生成所有分支
git branchstack

這會自動生成:

* local-branch (HEAD)
|   - [bugfix-123] Fix memory leak
|   - [profile-page:auth-refactor] Add profile component  
|   - [auth-refactor] Add JWT support
|   - [auth-refactor] Update login logic
|
|-- bugfix-123 (branch)
|     - Fix memory leak
|
|-- profile-page (branch)
|     - Add profile component
|     (based on auth-refactor)
|
|-- auth-refactor (branch)
      - Add JWT support
      - Update login logic

核心概念

  1. 標籤語法: [topic] 或 [topic:dependency]

    • [auth-refactor] - 獨立主題
    • [profile:auth-refactor] - profile 依賴 auth-refactor

  2. Branchless 開發體驗:

    • 所有工作在一個分支上進行
    • 不需要切換分支, build 不會失效
    • 修改任何 commit 後, 重跑 git branchstack 更新所有分支

  3. 利用 git-revise:

    • 底層使用 git-revise, 不碰工作目錄
    • 速度快, 不影響正在進行的工作

實際工作流

# 1. 開發階段 - 在本地分支上自由開發
git commit -m "[feature-A] Implement part 1"
git commit -m "[feature-A] Implement part 2"
git commit -m "[feature-B:feature-A] Build on A"

# 2. 需要修改之前的 commit
git revise --interactive --edit  # 編輯 commit message 加標籤
git revise <commit-hash>          # 或直接修改內容

# 3. 生成/更新分支用於 PR
git branchstack

# 4. 推送到 GitHub
git push origin feature-A
git push origin feature-B

優勢與限制

優勢:

  • 真正的 branchless 體驗, 留在本地分支工作
  • 自動處理依賴關係
  • 支援 git rerere 記住衝突解決方案
  • 永不修改工作目錄, 不影響 build

限制:

  • 主題得自己在 commit message 裡手動標
  • 依賴關係一變, 就得回去改 commit message
  • 連作者本人都已經轉去用 Jujutsu 了 (根據 git-branchstack README, 作者表示 jj 提供了更乾淨、也更強大的解法)

革命性轉變：Jujutsu (jj) — 重新定義個人版本控制體驗

為什麼誕生？

就算有了 git-revise 和 git-branchstack 這些工具, Git 骨子裡的那套模型, 摩擦還是擺在那裡。於是 Jujutsu 的作者 Martin von Zweigbergk (他同時也是 Google 內部版本控制系統的開發者) 乾脆下了決定: 與其一直在 Git 上面貼補丁, 不如從頭打造一個真正貼合現代工作流的版本控制系統。

我想這也不是為了把 Git 拉下「標準」的寶座, 而是想替那些真的很在意效率的個人開發者, 多開一條更好的路。

核心理念轉變

Jujutsu 不是在 Git 上面再加幾個工具而已, 而是整個重新想了一遍：版本控制到底該長什麼樣子:

  1. Change-based, 而非 Commit-based

    • 每個修改都是一個獨立的 “change”
    • Change 可以隨時修改, 不需要 amend 或 rebase

  2. Working Copy 即 Commit

    • 你的工作目錄就是一個 commit
    • 不需要 git add + git commit 兩階段

  3. 真正的非線性歷史

    • 不需要 branch 也能管理多條開發線
    • 衝突作為一等公民存在於歷史中

實際操作對比

場景一：修改歷史 Commit

Git 方式:

git rebase -i HEAD~3
# 標記要修改的 commit 為 'edit'
# 進行修改
git add .
git commit --amend
git rebase --continue

git-revise 方式:

# 進行修改
vim some_file.py
# Stage 修改
git add some_file.py
# 應用到目標 commit
git revise <commit-hash>  # 直接更新該 commit

Jujutsu 方式:

jj edit <change-id>  # 直接切換到該 change
# 進行修改
jj commit -m "updated"  # 自動更新該 change

場景二：管理多個功能開發

傳統 Git 方式:

git checkout -b feature-A
# 開發 feature-A
git commit -m "A"

git checkout -b feature-B
# 開發 feature-B
git commit -m "B"

# 要修改 A 時
git checkout feature-A
# 修改
git commit --amend
git checkout feature-B
git rebase feature-A  # 手動 rebase

git-branchstack 方式:

# 所有工作在本地分支進行
git commit -m "[feature-A] Implement A"
git commit -m "[feature-B:feature-A] Implement B"

# 生成分支
git branchstack

# 要修改 A 時
git add modified_files
git revise <commit-hash-of-A>  # 修改 A 的 commit

# 重新生成分支, 自動處理依賴
git branchstack

Jujutsu 方式:

# 不需要建立 branch
jj new -m "feature A"  # 創建新 change
# 開發 feature A

jj new -m "feature B"  # 基於當前創建新 change
# 開發 feature B

# 要修改 A 時
jj edit <change-A-id>
# 修改完自動處理依賴

Jujutsu 的核心特性

1. 自動追蹤所有歷史

jj op log  # 查看所有操作歷史
jj op undo  # 撤銷任何操作
jj op restore  # 恢復到任何時間點

完全不用碰 git reflog, 每一個操作都能回溯、也都能還原, 安心多了。

2. 衝突處理的新思路

# Jujutsu 讓你可以 commit 帶有衝突的狀態
jj new  # 即使有衝突也能繼續開發
jj resolve  # 稍後解決衝突

3. 與 Git 無縫協作

# Jujutsu 可以操作 Git repo
jj git clone <url>
jj git push
jj git fetch

# 現有 Git repo 也能用 jj
cd my-git-repo
jj init --git-repo .

為什麼 Jujutsu 是個人效率工具的終極形態？

心智模型更簡單

  • Git: Branch → Stage → Commit → Push → Rebase → Merge
  • Jujutsu: Change → Edit → Evolve

對個人開發者來說, 這就代表認知負擔更輕, 能多留點心思在真正要解的問題上。

更安全的實驗

  • 所有操作都可以輕鬆撤銷
  • 不需要擔心「搞壞」歷史
  • 鼓勵更頻繁的實驗和重構

更適合現代個人工作流

  • Code Review 驅動的開發
  • 頻繁的 Commit 修改
  • 多個 PR 同時進行
  • 不需要團隊統一工具 (可以單人使用 jj, 推送時轉為 Git)

實戰案例：用 Jujutsu 管理 Feature Stack

# 初始化
jj git clone https://github.com/user/repo.git
cd repo

# 創建第一個功能
jj new -m "Add user authentication"
# 開發...
jj describe -m "Add login form and validation"

# 基於此創建第二個功能
jj new -m "Add user profile page"
# 開發...

# 創建第三個功能
jj new -m "Add profile editing"
# 開發...

# 查看當前狀態
jj log

# 發現第一個功能需要修改
jj edit <auth-change-id>
# 修改...
jj describe -m "Updated authentication logic"

# 自動處理後續依賴, 不需要手動 rebase!

# 推送到 GitHub
jj git push --change <change-id>  # 為每個 change 推送對應分支

學習曲線

  1. 現有 Git 用戶: 可以繼續在 Git repo 中使用 jj, 逐步適應
  2. 新專案: 直接用 jj git init 開始, 享受完整體驗
  3. 團隊協作: 個人可以用 jj 提升效率, 推送時轉換為 Git, 不影響團隊其他成員

說到底, 這就是個個人選擇, 你不用為了它去說服整個團隊改工作流程。

結語：效率工具的個人化旅程

從 git-revise 到 git-branchstack, 再走到 Jujutsu, 這一路其實就是不斷在追問:版本控制到底該怎麼幫我做事。每個工具都是開發者對這個問題給出的、不太一樣的答案。

這幾個工具的共同點是:

  • 它們都是個人效率工具, 不必整個團隊一起採用
  • 它們都在挑戰 Git 既有的那套模式
  • 它們都想盡量減少摩擦, 讓你能更專心地解問題

Jujutsu 特別的地方在於, 它不只是把 Git 的某個地方修一修, 而是把整套版本控制的心智模型重新想過一遍。對願意花點時間學新工具、換長期效率的人來說, 它大概會是個不錯的選擇吧。

不過我也得說, 我並不建議你盲目地照單全收。最關鍵的還是那句:這是你自己的選擇。你不用等團隊有共識, 也不用去說服每一個人。如果 Git 的複雜常常讓你覺得累, 如果你想要更順的開發體驗, 那就動手試試這些工具囉。

或許你會發現, 想變得更有效率, 重點從來不是更拼命地用現有工具, 而是找到那個真正適合你的。

延伸資源

試試看,你可能再也回不去 Git 了! 🚀