https://appwrite.io/blog/post/10-git-commands-you-should-start-using#4-git-sparse-checkout-efficiently-handle-large-repositories

10 個你今天就應該開始使用的全新 Git 命令

1. git switch – 更安全的切換分支方式  
在 Git 2.23 之前，git checkout 是切換分支的主要命令，但它能做的事情遠不止于此：用它可以恢復文件、創建分支或檢出特定提交。這種強大也帶來了一定混淆——有時你只是想單純地切換分支，卻可能無意間對文件做出更改。

為此，Git 2.23 引入了 git switch，用以專注于分支操作，讓命令職責更加清晰：

# 切換到其他分支
git switch feature-branch

# 創建并切換到新分支
git switch -c new-branch

這一改動能有效降低誤操作的風險，比如不小心覆蓋了文件或進行意外更改。如果你之前在使用 git checkout 時會擔心“踩坑”，那么 git switch 就能讓切換分支簡化許多。

2. git restore – 安全地撤銷更改  
過去想撤銷更改時，可能會使用 git checkout 來還原文件，或用 git reset 來移動分支 HEAD。但使用不當的話，這兩條命令都有可能改變你的分支狀態：git reset 會移動你當前分支的 HEAD；git checkout 可能切換分支，或者檢出不同的提交，從而打斷當前分支的工作流程。

Git 2.23 推出了 git restore，它只專注于“撤銷文件的更改”，為工作區或暫存區提供安全明了的還原方式，也讓文件操作和分支管理區分得更清楚：

# 丟棄工作區中的修改
git restore main.js

# 從暫存區中移除修改
git restore --staged main.js

對于 Git 新手或者需要精準操作的場合，這尤其好用。這樣，你無需擔心會意外切換分支或重置提交，就能放心地撤銷文件修改。

3. git maintenance – 自動化地保持倉庫健康  
隨著倉庫規模的不斷增長，可能會出現性能下降的情況。諸如 git fetch、git status 或 git log 等操作都會變慢，而且倉庫中會積累一些無用的數據。以前，你需要手動執行類似 git gc（垃圾回收）或 git repack 命令來優化倉庫。

Git 2.29 引入了 git maintenance 來自動完成這些維護工作：

# 啟用自動維護
git maintenance start

# 立即運行清理任務
git maintenance run

其背后的原理主要包括：  
? 垃圾回收 (Garbage Collection)：移除無法再通過任何引用訪問的對象，比如在 rebase 或刪除分支時被丟棄的提交。  
? Repacking：合并分散的打包文件（packfile），提升存儲效率。  
? 提交圖更新 (Commit Graph Updates)：優化提交歷史的遍歷速度，加快 git log 和 git blame 等命令的執行。  

使用 git maintenance 能讓你無需反復手動維護，就能保持倉庫的高效和整潔。

4. git sparse-checkout – 高效處理大型倉庫  
Monorepo（單體式倉庫）在管理多個項目時很有用，但如果你只需要其中某個子目錄的內容，卻要被迫完整克隆整個倉庫，那就顯得很低效。為此，Git 2.25 推出了 git sparse-checkout：

# 啟用 sparse-checkout 模式
git sparse-checkout init

# 只獲取指定的目錄
# 可用空格分隔多個目錄
git sparse-checkout set services/ docs/

使用 git sparse-checkout 你可以只包含需要的目錄或文件，其余的部分不會出現在工作區中。對于在同一個 monorepo 中協作、但只關注特定業務模塊的團隊而言，這能大幅節省時間和磁盤空間。

5. git log --remerge-diff：更好地理解合并  
Merge 提交通常只告訴我們合并了哪個分支，但并不總能展示合并過程中引入的具體更改，尤其是在有沖突并解決后。

從 Git 2.35 開始，你可以使用：

git log --remerge-diff

這個選項會基于記錄的合并策略重演合并提交，并展示其中引入的實際更改。它在調試合并沖突或者回顧復雜的合并歷史時相當實用。

6. git blame --ignore-rev – 忽略噪音式提交  
當團隊進行大規模的格式化更改后，git blame 可能就失去了參考價值，因為所有行都指向了那個“格式調整提交”，而不再是原作者。

Git 2.23 中引入了 --ignore-rev 選項，用來忽略這類提交：

git blame --ignore-rev 提交哈希

想要讓這個忽略持久化，可以在項目中設置一個 ignore-revs 文件：

# 將提交哈希添加進 ignore-revs 文件
echo 提交哈希 >> .git-blame-ignore-revs

# 告訴 Git 使用該文件
git config blame.ignoreRevsFile .git-blame-ignore-revs

這樣，你就能更準確地關注有意義的提交者，尤其適用于經常有格式化提交的代碼庫。

7. git range-diff – 對比并追蹤提交區間間的變化  
無論是通過 rebase、cherry-pick 還是交互式編輯，對提交歷史進行重寫的操作都可能比較復雜。當我們做完一次 rebase 后，可能想知道重寫后的提交與原始提交具體有什么區別。git range-diff 則能幫我們比較兩個提交區間，展示它們之間的演進，并突出每個提交的變化差異：

git range-diff

這個命令可以覆蓋在多分支、多階段的迭代開發場景中，以幫助了解一個功能或 bug 修復在不同分支上的演化過程。

8. git worktree – 同時在多個分支上工作  
在同一個工作區頻繁切換分支會打斷工作流程，尤其是當你需要并行處理多個分支的時候。git worktree 允許你為同一個倉庫創建額外的工作區：

# 為某個分支添加一個新的工作區
git worktree add ../feature-branch feature-branch

# 完成后刪除該工作區
git worktree remove ../feature-branch

使用 git worktree 你能在不同工作區中同時處理多個分支，而無需來回切換或 stash。你也可以創建臨時性的工作區（處于分離 HEAD 狀態）來做測試，或者在單獨的工作區里執行構建和部署操作。

9. git rebase --update-refs – 保持引用同步  
Rebase 操作會用新的提交替換舊的提交，導致一些分支指針或標簽仍然引用了被舍棄的舊提交。Git 2.38 引入了 --update-refs 選項來自動處理這種情況：

git rebase --update-refs

在執行此命令時，Git 會確保那些引用了被重寫提交的相關分支和標簽都與新的歷史保持一致，省去了手動更新的繁瑣，也能讓倉庫中的引用保持一致。

如果你還想更細粒度地控制，可以進行以下配置，讓 rebase 總是更新指定引用：

git config rebase.updateRefs true

當你在協作或需要管理多個引用時，這項功能將大大簡化流程。

10. git commit --fixup 與 git rebase --autosquash – 修正型提交  
雖然這并不是新功能（在 Git 1.7.4，就已推出），但 git commit --fixup 常常被忽略。它卻是保證提交歷史整潔的強大工具。開發功能時，如果你需要修復或改進先前的某個提交，手動修改提交歷史并不一定穩定。Git 為此提供了 git commit --fixup 與 git rebase --autosquash：

# 創建一個 fixup commit，目標是特定的提交
git commit --fixup=<提交哈希>

# 在稍后的交互式 rebase 中，自動地把 fixup commit 合并到目標提交
git rebase -i --autosquash <基準分支>

--fixup 會創建一個特殊的提交標記，用于在后續執行帶有 --autosquash 的交互式 rebase 時，自動將該提交合并進目標提交。這樣，你就能在合并代碼前，更加輕松地整理提交歷史，并將相關改動歸納到一起，無需手動挪動提交。

結論  
文中介紹的這些命令，能幫助你解決日常 Git 使用中可能遇到的實際問題。無論你是在管理 monorepo，大規模操作歷史，還是想讓倉庫持續健康，這些命令都能提供很大的助力。不妨先挑一兩個嘗試融入自己的工作流，你很可能會發現，在提高工作效率方面，它們比想象中更給力。

如果你喜歡這篇文章，不妨再看看 “15 個每位開發者都應該知道的 Git 命令行技巧”。