Git Is Not Fine: Rethinking Version Control for Modern Workflows

版本控制的產業標準在近二十年來幾乎沒有改變。雖然 Git 無處不在，但越來越多的開發者發現，其核心架構（最初是為 Linux kernel 設計的）與現代、迭代且通常是非線性的開發流程並不完全契合。

最近圍繞著「Git Is Not Fine」論點的討論顯示，我們只是學會了如何應對其限制，而不是解決它們。從管理堆疊 PR 的掙扎到 index（暫存區）帶來的摩擦，我們用來追蹤變更的工具與我們實際編寫程式碼的方式日益衝突。

The Friction of the Linear Mindset

Git 的架構從根本上是基於 commit 的串流。然而，現代開發——特別是在大型 monorepos 中——很少是一條直線。開發者經常發現自己同時在處理多個功能，其中一個 package 中的微小修復可能需要用來支援另一個功能中的功能。

正如一位開發者在最近的 Hacker News 討論中所提到的，挑戰不僅僅是切換分支，而是管理一個「樹狀」的工作流：

我在做一件事，但它會導致其他 package 的變更，而我沒有明確的方法可以說：這些變更屬於 branch #1，另外那一組變更屬於 branch #2，而另一個微小的修復屬於 branch #3。branch #1 依賴於其他分支... 切換分支並不是解決方案，因為所有這些變更都是同時進行開發的。

在這種環境下，傳統的 Git workflow 像是 stashing 或 worktrees 通常是不夠的。手動追蹤哪些變更屬於哪個邏輯工作單位的認知負荷，成為了生產力上的重大負擔。

The "Muscle Memory" Fallacy

有一個常見的反對論點：Git 的複雜度僅僅是學習曲線的問題。許多經驗豐富的開發者認為，rebasing、管理 submodules 以及重寫 commit history 是「肌肉記憶」的問題。

我處理堆疊 PR/branches 的方式是 rebase 最最後一個。然後對其他分支簡單地使用 git branch -f a-branch <logical same point on rebased>，就完成了。這一切都變成了肌肉記憶。

然而，這種對肌肉記憶的依賴暗示了一個問題。當一個工具的主要介面要求使用者必須記住複雜的指令序列來執行常見任務時，該工具就不再是促進工作的工具，而是變成了工作本身。AI 輔助編碼的出現進一步使情況複雜化，因為開發者現在使用 LLMs 來執行快速的、輔助性任務，同時專注於主要功能，從而創造出更加碎片化的工作流。

Beyond Git: The Rise of New Alternatives

關於 Git 不足之處的爭論並非沒有先例。文章強調了像 Meta 這樣的大型公司長期以來一直使用基於 Mercurial 的內部系統來處理其 monorepos 的規模與複雜度，證明了更有效率的變更追蹤方式確實存在。

這促使了像 Jujutsu (jj) 這樣工具的出現，其目標是解決 Git 的一些核心挫折感。透過將 commits 視為可變的（mutable）並重新思考如何追蹤工作目錄的狀態，jj 試圖減少與 staging area 及其「detached HEAD」狀態相關的摩擦。

Conclusion: Is Git Truly "Not Fine"?

無論 Git 是一個「不夠好」的版本控制系統，還是我們已經超越了它的能力，結果都是一樣：工具與現代開發者的心理模型之間存在著鴻溝。雖然有些開發者發現目前的 Git workflow 夠應對其特定的語言或專案規模，但其他人——特別是那些在大型、分散式環境中的開發者——發現 Git 架構的限制正成為一個不可避免的瓶頸。