Git 設計問題

盡管 Git 被廣大程序員所推崇，但它并非完美無缺，也不適用于所有場景。

命令繁多且易混淆

• Git 至少有 157 個命令，常用的可能僅有十個。
• 更麻煩的是，你可能會發現經常使用的命令與實際操作不完全對應，這會增加認知負擔。通常，你需要組合多個命令來實現目標，說明 Git 的命令設計過于底層。

暫存區（staging area）

暫存區是 Git 倉庫的關鍵部分，負責協調和管理文件變更。優點：

1. 暫存變更：當你修改文件后，Git 會將變更暫存在暫存區，而非直接應用到倉庫。這樣，你可以在提交前查看和驗證變更，確保符合預期。
2. 控制提交：暫存區有助于有目的地進行提交。如果沒有暫存區，每次修改文件，Git 都會自動提交變更，可能導致頻繁提交，難以回滾。使用暫存區，你可以更有意識地管理提交，避免不必要的沖突和錯誤。
3. 簡化提交操作：暫存區使得提交過程更簡單。只需將所需更改暫存，然后一次性提交到倉庫。減少多次提交操作，提高工作效率。
4. 便于回滾：暫存區讓你在提交變更前查看和修復問題。若在暫存區發現問題，可直接回滾到之前版本，無需擔心之前的修改。降低錯誤影響，加快修復速度。
5. 版本控制：暫存區有助于更好地進行版本控制。開發過程中，可以將暫存區的變更與特定版本關聯，便于需要時回滾到之前版本。對大型項目尤為重要，保持項目穩定性，同時允許團隊成員進行實驗性開發。

缺點：

復雜性增加：對于初學者，暫存區的概念可能較難理解。

全新工具助力 git

許多新工具致力于改進 git 的用戶體驗，根據我個人的觀察，這些改進主要集中在簡化命令、清除暫存區、推崇單一主干分支理念以及 stack 工作流。其中，stack 工作流尤為值得一提，下面將以 meta 的 sapling 為例進行講解。

stack 工作流

使用過 git 的朋友們應該都能體會到 rebase 的優勢，但在實際操作中，人們往往感到困惑。以下是一個典型場景：

1. 首先，a 基于 AB 進行開發。
2. 隨后，需求 b 基于 AB 中的 B 部分展開。
3. 原本計劃發布的 a 推遲了，導致 b 希望盡早發布。
4. 此時，人們希望將 AB 拆分為 A 和 B 的最小改動，讓 b 從 B 進行 rebase。
5. 最后，我們可以以最小影響發布 b + B。

圖片

在這個過程中，git 的操作顯得不那么友好，提交是線性維度的。要更好地控制 git，只能開啟新分支，而若要從中間拆分分支，則需要手動處理大量后續節點。sapling 就在這方面提供了 stack 工作流的支持。

1. 僅關注相關倉庫和提交，無關提交不顯示無關倉庫甚至無需下載。
2. 本地分支甚至無需命名，全自動化管理，自然也省去了暫存區。
3. 無需使用 rebase，而是提供了 split fold 等操作，遵循一個命令只完成一個任務且能 undo 的思路，精心設計。
4. 增加了 git 所不具備的變更記錄，便于進行自動化操作，例如，在 A-B-C 提交中，將 A 合入 master。sapling 能根據新增的 A-master 記錄，自動將 B-C rebase 到 master。

在多人合作開發中，很多團隊可能無法直接進入主干開發模式，更多的情況是：

1. 基建 AB 需要進一步拆分為更多層級，以合理維護依賴鏈。
2. 由于一直未合入，新需求 c 加入，需要從 AB 再次拆分為依賴 AB-C 的復雜形式。
3. 同樣，由于無法合入，a、b、c 均需單獨提測。此時，git 中很可能面臨數百個提交、數千個變更的混亂局面，幾乎失控。若要堅持多個分支 rebase，每次更新鏈路需執行數十甚至上百個命令。
4. sapling 針對這種情況進行了專門設計，實現單個鏈路自動化 rebase，code review、合并、測試等環節優雅無縫！

圖片

最后，如果 sapling 對你來說改動過大（暫不兼容 gitlab），可以嘗試另一個開源項目 git town，它也是 stack 工作流的一部分。

https://www.highflux.io/blog/highflux-method https://sapling-scm.com/docs/introduction/differences-git https://www.git-town.com/