Git reset 與 revert 還原更動

git reset

將 HEAD 指向其他 commit

Git 提供三種 reset 模式，可根據不同需求還原專案狀態：

區域名稱 說明
HEAD 目前指向的 commit
Staging Area 暫存區，下一次 commit 的候選更動
Working Directory 實際檔案，開發者正在編輯的地方

運作原理與模式比較

--soft

  • 僅移動 HEAD 指向，不影響暫存區與工作目錄
  • 適合重組 commit，例如合併多個 commit
git reset --soft <commit>

--mixed（預設）

  • 移動 HEAD，並將暫存區還原為指定 commit 的狀態
  • 工作目錄不變，會顯示為未暫存變更（unstaged changes）
git reset --mixed <commit>

--hard

  • 同步 HEAD、暫存區、工作目錄為指定 commit 狀態
  • 所有未儲存變更將永久刪除，無法復原
git reset --hard <commit>

使用情境與範例

清除最近的 commit（未 push）

git reset --soft HEAD~1
  • 撤回上一次 commit，保留變更，可修改後重新 commit（常與 --amend 一起使用）

清除暫存，但保留變更

git reset --mixed HEAD
  • 取消所有 git add 的檔案，但保留檔案修改
  • 適合取消加入過多的暫存檔案

完全回復為某個 commit 狀態

git reset --hard abc123
  • 所有未儲存變更將刪除，僅保留指定 commit 狀態

注意事項

  • --hard 模式會永久刪除工作目錄與暫存區內容，無法復原
  • reset 會改變 Git 歷史，已推送的 commit 不應 reset，以免造成版本衝突
  • HEAD 被移動後，可能會搞不清楚目前所在 commit，需謹慎操作

git revert

核心概念

git revert 會 建立一個新的 commit，內容為指定 commit 的反向更動：

  • 不會刪除或撤銷原始 commit
  • 是「反向提交」而非「刪除提交」

推送到遠端的情況

  • 不應使用 reset 變更歷史，否則其他協作者會產生衝突
  • 使用 revert 為非破壞性方式，可安全還原特定更動

多人協作情境

  • 為維護穩定共用歷史，應避免使用 reset
  • revert 是安全且可追蹤的方式，適合多人協作流程

使用情境

還原錯誤功能

  • 某功能上線後發現 bug，可 revert 該功能的 commit
  • 修復完成後再重新提交

還原特定 commit 的影響

  • 不需回到過去，只是取消其中一筆不當更動

工作原理

假設 Git 歷史如下：

A -- B -- C -- D (HEAD)

發現 C 有問題：

git revert C

Git 會產生一個新的 commit E：

A -- B -- C -- D -- E (HEAD)

其中 E 的內容為 C 的反向操作

注意事項

情況 說明
衝突發生 如果目標 commit 與目前狀態衝突（尤其是 revert merge commit），會產生 conflict，需要手動解決
重複 revert 不應重複還原同一個 commit，否則會反覆新增正負變化，造成混亂
還原合併 commit 必須使用 --mainline，語意不易理解，也容易出錯
歷史雜亂 太多 revert 會讓 Git 歷史難以閱讀，建議搭配明確 commit message 解釋原因 
- `git reset` 適用於開發過程中，尚未推送的 commit 整理與清除
- `git revert` 適用於已推送或多人協作情境，是安全的回復方式