為什么 git revert 比 git reset 更適合團隊協作

git revert 創建新提交來撤銷舊提交的更改，而 git reset 直接改寫歷史。在共享分支（比如 main 或 develop）上，重寫歷史會破壞其他人的本地副本：他們拉取時會遇到沖突、丟失提交，甚至誤刪工作。

場景對比

假設你在 main 上提交了 bad-commit，現在想撤回：

• ? git revert bad-commit
  生成一個新提交，內容是 bad-commit 的逆向補丁。所有人 git pull 就能同步修復，歷史線性增長，無副作用。
• ? git reset --hard HEAD~1
  本地 main 指針退回上一個提交，bad-commit 從分支歷史中消失。但別人本地仍有該提交——他們下次 git pull 時，Git 會嘗試合并兩個分叉，可能觸發不必要的沖突；更糟的是，如果有人基于 bad-commit 繼續開發，reset 后他們的后續提交會變成“懸空”，容易被 GC 清理。

關鍵區別

實用建議

• 共享分支（main/release/團隊功能分支）一律用 revert
• 本地未推送的 feature 分支，可用 reset 整理提交（如 fixup、squash）
• 撤銷多個連續提交：git revert HEAD~2..HEAD（注意范圍是 A..B 表示 從 A 之后到 B，不包含 A）
• 撤銷非連續提交：多次 git revert <commit-hash>，或一次性 git revert hash1 hash2 hash3

一個真實例子

# 錯誤：在已推送到遠程的 main 上硬重置
$ git checkout main
$ git reset --hard HEAD~1
$ git push --force origin main  # 危險！強制推送會覆蓋他人歷史

# 正確：用 revert 安全修復
$ git checkout main
$ git revert abc1234  # abc1234 是問題提交哈希
$ git push origin main  # 普通推送，所有人可安全拉取

revert 不是“不夠快”的妥協，而是協作前提下的必要設計。它讓撤銷操作可追溯、可審計、可協作——就像數據庫里的 DELETE 和 TRUNCATE，語義和影響完全不同。