當你的寫好的製作樂高手冊突然發現，有重大的錯誤、少了一些步驟，想要修改重寫，我們會怎麼做？通常我們會移除手冊上有問題的部分，從已經完成，沒有問題的地方繼續開始。

GIT 怎麼作 reset 呢？

如果是 GIT 版本控制呢？在 GIT 裡，有一個指令是 git reset 在這後面可以指定 git 的 HASH CODE，例如：git reset ABC 那麼 git 就會幫你把儲存庫還原到 ABC 執行後的樣子。接下來我們用三個初始情境都醫致的例子，來講解 git reset 常見的三種參數，分別是：--mixed、--soft、--hard。

在官方手冊上，是這樣解釋 git reset 指令的：

Reset current HEAD to the specified state

情境介紹

現在儲存庫總共有三個 commit 對應三個 HASH CODE，依據先後順序，先的擺放在前面分別是：A、B、C，目前的 master 指向 C 及 HEAD 指在 master 上。

情境一：儲存庫回到 B 為最新版本，但 C 的變更不消失留在工作區

• 搭配指令：git reset --mixed HEAD^ 或 git reset HEAD^

使用情境：當發現 HASH C 這個 commit 的變化內容，有一些可能不需要紀錄在這個 commit 上，或者是想保留這次的變化，自己重新 add 變化到舞台區，就可以使用 --mixed 這個參數。--mixed 參數是 reset 的預設值，因此不加就直接是 --mixed 了。

選擇 HASH B 這個位置，除了可以在 --mixed 後面加上 HASH B，因為 B 這個位置，就是 C 的上一步，因此使用前幾天提到的 HEAD^，如此就不用特別去查出上一步的 HASH CODE。

情境二：儲存庫回到 B 為最新版本，但 C 的變更留在舞台區

• 搭配指令：git reset --soft HEAD^ 

使用情境：當發現，HASH C 這個 commit 再增加一些原始碼變更，紀錄在同一個 commit 上會比較好時，就可以選擇加上 --soft 參數，讓紀錄在 HASH C 上面的變化，回到舞台區，等待補齊要一起上 commit 的變更之後，再次 commit。

值得注意的小地方，當重新 commit 後的 HASH Code 將不會和原本的HASH C一模一樣，因為 GIT 依據這次的變化，重新幫你產生了新的 HASH Code。

情境三：儲存庫回到 B 為最新版本，但 C 的變更完全不想保留

• 搭配指令：git reset --hard HEAD^ 

使用情境：當發現，HASH C 這個 commit 完完全全的不需要，應該丟掉連痕跡都不留，這時候就可以選擇加上 --hard 這個參數。

總結：

GIT git reset 指令，就好像時光機，讓我們可以回到過去，砍掉重練，重新來過一次。但要特別注意，當有團隊合作的情境時，大家共用遠端的儲存庫，砍掉重練這件事情，要特別想清楚，因為你造成的變化，不止是你本地原始碼儲存庫的變化，可能影響到團隊夥伴手上的儲存庫。剩下的，等之後講解遠端協作的時候再繼續細說。