【Git】reset, checkout 和 revert 命令比較

Git是一個強大分佈式增量版本控件工具，具有非常強大的功能。功能強大同時也意味着使用時有一定的複雜性。本文就以恢復錯誤爲例，就有三條可用的命令：reset, checkout 和 revert。下面就讓我們來看看它們有什麼不同。

簡述

在《【Git實戰記錄】撤銷已經提交至遠程的一次變更》一文中，對其比較如下：
相同點：都是用於恢復數據
不同點：

• reset 用於將本地數據從當前版本V1恢復至某個版本V0，同時將V0之後的所有提交全部丟棄
• checkout 僅僅刪除當前所有變化，恢復至最後一次同步時的狀態
• revert 將某次提交時的變化恢復至本地，作爲一次新的變更。

但是，這些描述並不具體，下面我們以實例來看看。

checkout

在這三條命令中，checkout 是最輕量級的恢復。它的作用是在所有數據都是已經同步的狀態下，如果對本地文件 a 進行了修改後發現此修改是多餘的，且還未對 a 執行 commit 操作，那麼就可以使用 checkout 將 a 恢復至原先同時時的狀態。在命令執行後，a 的多餘的修改不會有任何的記錄。一般用於恢復一些僅在本地保存的誤操作。

reset

如果在以上的修改後，已經對 a 執行了 commit 操作，即已經將對 a 的修改提交至本地庫，那麼這時候 reset 就是我們的後悔藥。設原歷史有3個版本，順序爲：
$V_0 \rightarrow V_1\rightarrow V_2$

然後在提交了錯誤的修改，這時歷史版本變爲：$V_0 \rightarrow V_1 \rightarrow V_2 \rightarrow V_3$

其中，最新的 $V_3$ 爲錯誤的版本。

這時候，我們如果執行 reset 命令，並且指定回到 $V_2$ 版本，那麼 $V_3$ 就會被刪除，不會留下任何痕跡，歷史版本狀態會回到初始的三個版本，即$V_0 \rightarrow V_1\rightarrow V_2$。

注意：已 push 到遠程倉庫的不允許 reset。這是因爲在提交至遠程倉庫後，就意味着此版本別人可能已經在使用了，如果仍然允許 reset，就可能會引發其他人員提交版本的丟失，從而導致災難性的後果。

revert

雖然 reset 能夠撤銷錯誤的版本，但是這種做法很多時候並不推薦，因爲這樣的做法把錯誤的版本丟棄了，造成了信息的丟失並不適合Git精神，即記錄版本控制過程中的所有變化情況。所以，這裏推薦使用 revert 命令。它的作用是，在保留錯誤版本的前提下，恢復到指定的版本。

同樣讓我們以上面的三個版本，即$V_0 \rightarrow V_1 \rightarrow V_2$爲例。在提交了錯誤的版本後，變爲$V_0 \rightarrow V_1 \rightarrow V_2 \rightarrow V_3$。此時，我們執行 revert 恢復至 $V_2$ 版本，那麼版本歷史會變成：$V_0 \rightarrow V_1 \rightarrow V_2 \rightarrow V_3 \rightarrow V_2^+$

此時，我們會發現歷史版本變成了5個，多了一個$V_2^+$，這個版本的內容與 $V_2$ 完成一致，但是是作爲一個全新的提交而存在。這樣即達到了恢復到 $V_2$ 版本的目的，同時又保存了錯誤版本 $V_3$，從而保證了信息的完全性。當然，這樣做肯定會佔用更多的磁盤空間，但是我們通常認爲信息本身比磁盤更重要，所以推薦使用 revert 命令保留錯誤的提交。

如果對 revert 和 revert 命令還不理解，可以看一下官方給的一個圖例，能夠非常好地說明問題（上面是revert，下面是 reset）：