撤銷一個“已公開”的改變
場景: 你已經(jīng)執(zhí)行了 git push, 把你的修改發(fā)送到了 GitHub，現(xiàn)在你意識到這些 commit 的其中一個是有問題的，你需要撤銷那一個 commit.
方法:
git revert SHA>
原理: git revert 會產(chǎn)生一個新的 commit，它和指定 SHA 對應(yīng)的 commit 是相反的（或者說是反轉(zhuǎn)的）。如果原先的 commit 是“物質(zhì)”，新的 commit 就是“反物質(zhì)” — 任何從原先的 commit 里刪除的內(nèi)容會在新的 commit 里被加回去，任何在原先的 commit 里加入的內(nèi)容會在新的 commit 里被刪除。
這是 Git 最安全、最基本的撤銷場景，因為它并不會改變歷史 — 所以你現(xiàn)在可以 git push 新的“反轉(zhuǎn)” commit 來抵消你錯誤提交的 commit。
撤銷“本地的”修改
場景: 一只貓從鍵盤上走過，無意中保存了修改，然后破壞了編輯器。不過，你還沒有 commit 這些修改。你想要恢復(fù)被修改文件里的所有內(nèi)容 — 就像上次 commit 的時候一模一樣。
方法:
git checkout -- bad filename>
原理: git checkout 會把工作目錄里的文件修改到 Git 之前記錄的某個狀態(tài)。你可以提供一個你想返回的分支名或特定 SHA ，或者在缺省情況下，Git 會認(rèn)為你希望 checkout 的是 HEAD，當(dāng)前 checkout 分支的最后一次 commit。
記住：你用這種方法“撤銷”的任何修改真的會完全消失。因為它們從來沒有被提交過，所以之后 Git 也無法幫助我們恢復(fù)它們。你要確保自己了解你在這個操作里扔掉的東西是什么?。ㄒ苍S可以先利用 git diff 確認(rèn)一下）
Git倉庫撤銷至前一次提交時的狀態(tài)
$ git checkout SHA>
“”是你想查看的提交擁有的哈希值Hash Code中前8至10個字符。 這個命令會使HEAD>指針脫離detach，可以讓你在不檢出check out任何分支的情況下查看代碼——脫離HEAD并不像聽上去那么可怕。如果你想在這種情況下提交修改，你可以通過創(chuàng)建新的分支來實(shí)現(xiàn)：
$ git checkout -b SHA>
要想回到當(dāng)前的工作進(jìn)度，只需要檢出check out你之前所在的分支即可。
撤銷最近一次代碼提交
有時候你可能會不小心提交了錯誤的文件或一開始就遺漏了某些東西。下面這三步操作可以幫助你解決這個問題。
$ git reset --soft HEAD~1
# 對工作文件進(jìn)行必要的更改
$ git add -A .
$ git commit -c ORIG_HEAD
你執(zhí)行第一個命令時，Git會將HEAD指針后移到此前的一次提交，之后你才能移動文件或作必要的修改。
然后你就可以添加所有的修改，而且當(dāng)你執(zhí)行最后的命令時，Git會打開你的默認(rèn)文本編輯器，其中會包含上一次提交時的信息。如果愿意的話，你可以修改提交信息，或者你也可以在最后的命令中使用-C而不是-c，來跳過這一步。
撤銷合并Merge
要想撤銷合并，你可能必須要使用恢復(fù)命令HARD RESET回到上一次提交的狀態(tài)。“合并”所做的工作基本上就是重置索引，更新working tree（工作樹）中的不同文件，即當(dāng)前提交（）代碼中與HEAD游標(biāo)所指向代碼之間的不同文件；但是合并會保留索引與working tree之間的差異部分（例如那些沒有被追蹤的修改）。
$ git checkout -b SHA>
在撤銷“本地修改”之后再恢復(fù)
場景: 你提交了幾個 commit，然后用 git reset --hard 撤銷了這些修改（見上一段），接著你又意識到：你希望還原這些修改！
方法:
git reflog
和
git reset
或
git checkout
原理: git reflog 對于恢復(fù)項目歷史是一個超棒的資源。你可以恢復(fù)幾乎 任何東西 — 任何你 commit 過的東西 — 只要通過 reflog。
你可能已經(jīng)熟悉了 git log 命令，它會顯示 commit 的列表。 git reflog 也是類似的，不過它顯示的是一個 HEAD 發(fā)生改變的時間列表.
一些注意事項：
它涉及的只是 HEAD 的改變。在你切換分支、用 git commit 進(jìn)行提交、以及用 git reset 撤銷 commit 時，HEAD 會改變，但當(dāng)你用 git checkout -- bad filename> 撤銷時（正如我們在前面講到的情況），HEAD 并不會改變 — 如前所述，這些修改從來沒有被提交過，因此 reflog 也無法幫助我們恢復(fù)它們。
git reflog 不會永遠(yuǎn)保持。Git 會定期清理那些 “用不到的” 對象。不要指望幾個月前的提交還一直躺在那里。
你的 reflog 就是你的，只是你的。你不能用 git reflog 來恢復(fù)另一個開發(fā)者沒有 push 過的 commit。
大量的撤銷/恢復(fù)
場景: 你向某個方向開始實(shí)現(xiàn)一個特性，但是半路你意識到另一個方案更好。你已經(jīng)進(jìn)行了十幾次提交，但你現(xiàn)在只需要其中的一部分。你希望其他不需要的提交統(tǒng)統(tǒng)消失。
方法:
git rebase -i earlier SHA>
原理: -i 參數(shù)讓 rebase 進(jìn)入“交互模式”。它開始類似于前面討論的 rebase，但在重新進(jìn)行任何提交之前，它會暫停下來并允許你詳細(xì)地修改每個提交。
rebase -i 會打開你的缺省文本編輯器，里面列出候選的提交。如下所示：
前面兩列是鍵：第一個是選定的命令，對應(yīng)第二列里的 SHA 確定的 commit。缺省情況下， rebase -i 假定每個 commit 都要通過 pick 命令被運(yùn)用。
要丟棄一個 commit，只要在編輯器里刪除那一行就行了。如果你不再需要項目里的那幾個錯誤的提交，你可以刪除上例中的1、3、4行。
如果你需要保留 commit 的內(nèi)容，而是對 commit 消息進(jìn)行編輯，你可以使用 reword 命令。 把第一列里的 pick 替換為 reword (或者直接用 r)。有人會覺得在這里直接重寫 commit 消息就行了，但是這樣不管用 —rebase -i 會忽略 SHA 列前面的任何東西。它后面的文本只是用來幫助我們記住 0835fe2 是干啥的。當(dāng)你完成 rebase -i 的操作之后，你會被提示輸入需要編寫的任何 commit 消息。
如果你需要把兩個 commit 合并到一起，你可以使用 squash 或 fixup 命令，如下所示：
squash 和 fixup 會“向上”合并 — 帶有這兩個命令的 commit 會被合并到它的前一個 commit 里。在這個例子里， 0835fe2 和 6943e85 會被合并成一個 commit， 38f5e4e 和 af67f82 會被合并成另一個。
如果你選擇了 squash， Git 會提示我們給新合并的 commit 一個新的 commit 消息； fixup 則會把合并清單里第一個 commit 的消息直接給新合并的 commit 。 這里，你知道 af67f82 是一個“完了完了….” 的 commit，所以你會留著 38f5e4e as的 commit 消息，但你會給合并了 0835fe2 和 6943e85 的新 commit 編寫一個新的消息。
在你保存并退出編輯器的時候，Git 會按從頂部到底部的順序運(yùn)用你的 commit。你可以通過在保存前修改 commit 順序來改變運(yùn)用的順序。如果你愿意，你也可以通過如下安排把 af67f82 和 0835fe2 合并到一起：
