Git 設(shè)計(jì)問(wèn)題

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

命令繁多且易混淆

• Git 至少有 157 個(gè)命令，常用的可能僅有十個(gè)。
• 更麻煩的是，你可能會(huì)發(fā)現(xiàn)經(jīng)常使用的命令與實(shí)際操作不完全對(duì)應(yīng)，這會(huì)增加認(rèn)知負(fù)擔(dān)。通常，你需要組合多個(gè)命令來(lái)實(shí)現(xiàn)目標(biāo)，說(shuō)明 Git 的命令設(shè)計(jì)過(guò)于底層。

暫存區(qū)（staging area）

暫存區(qū)是 Git 倉(cāng)庫(kù)的關(guān)鍵部分，負(fù)責(zé)協(xié)調(diào)和管理文件變更。優(yōu)點(diǎn)：

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

缺點(diǎn)：

復(fù)雜性增加：對(duì)于初學(xué)者，暫存區(qū)的概念可能較難理解。

全新工具助力 git

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

stack 工作流

使用過(guò) git 的朋友們應(yīng)該都能體會(huì)到 rebase 的優(yōu)勢(shì)，但在實(shí)際操作中，人們往往感到困惑。以下是一個(gè)典型場(chǎng)景：

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

圖片

在這個(gè)過(guò)程中，git 的操作顯得不那么友好，提交是線性維度的。要更好地控制 git，只能開(kāi)啟新分支，而若要從中間拆分分支，則需要手動(dòng)處理大量后續(xù)節(jié)點(diǎn)。sapling 就在這方面提供了 stack 工作流的支持。

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

在多人合作開(kāi)發(fā)中，很多團(tuán)隊(duì)可能無(wú)法直接進(jìn)入主干開(kāi)發(fā)模式，更多的情況是：

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

圖片

最后，如果 sapling 對(duì)你來(lái)說(shuō)改動(dòng)過(guò)大（暫不兼容 gitlab），可以嘗試另一個(gè)開(kāi)源項(xiàng)目 git town，它也是 stack 工作流的一部分。

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

當(dāng)前題目：Git難用？有救！
地址分享：http://uogjgqi.cn/article/dhgpphp.html