重置“本地的”修改

場景: 你在本地提交了一些東西（還沒有 push），但是所有這些東西都很糟糕，你希望撤銷前面的三次提交 — 就像它們從來沒有發(fā)生過一樣。

方法: git reset last good SHA> 或 git reset --hard last good SHA>

原理: git reset 會把你的代碼庫歷史返回到指定的 SHA 狀態(tài)。 這樣就像是這些提交從來沒有發(fā)生過。缺省情況下， git reset 會保留工作目錄。這樣，提交是沒有了，但是修改內(nèi)容還在磁盤上。這是一種安全的選擇，但通常我們會希望一步就“撤銷”提交以及修改內(nèi)容 — 這就是 --hard 選項(xiàng)的功能。

在撤銷“本地修改”之后再恢復(fù)

場景: 你提交了幾個 commit，然后用 git reset --hard 撤銷了這些修改（見上一段），接著你又意識到：你希望還原這些修改！

方法: git reflog 和 git reset 或 git checkout

原理: git reflog 對于恢復(fù)項(xiàng)目歷史是一個超棒的資源。你可以恢復(fù)幾乎 任何東西 — 任何你 commit 過的東西 — 只要通過 reflog。

你可能已經(jīng)熟悉了 git log 命令，它會顯示 commit 的列表。 git reflog 也是類似的，不過它顯示的是一個 HEAD 發(fā)生改變的時間列表.

一些注意事項(xiàng)：

      它涉及的只是 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。
reflog

那么…你怎么利用 reflog 來“恢復(fù)”之前“撤銷”的 commit 呢？

它取決于你想做到的到底是什么：

     如果你希望準(zhǔn)確地恢復(fù)項(xiàng)目的歷史到某個時間點(diǎn)，用 git reset --hard SHA>

     如果你希望重建工作目錄里的一個或多個文件，讓它們恢復(fù)到某個時間點(diǎn)的狀態(tài)，用 git checkout SHA> -- filename>

     如果你希望把這些 commit 里的某一個重新提交到你的代碼庫里，用 git cherry-pick SHA>

利用分支的另一種做法

場景: 你進(jìn)行了一些提交，然后意識到你開始 check out 的是 master 分支。你希望這些提交進(jìn)到另一個特性（feature）分支里。

方法: git branch feature, git reset --hard origin/master, and git checkout feature

原理: 你可能習(xí)慣了用 git checkout -b name> 創(chuàng)建新的分支 — 這是創(chuàng)建新分支并馬上 check out 的流行捷徑 — 但是你不希望馬上切換分支。這里， git branch feature 創(chuàng)建一個叫做 feature 的新分支并指向你最近的 commit，但還是讓你 check out 在 master 分支上。

下一步，在提交任何新的 commit 之前，用 git reset --hard 把 master 分支倒回 origin/master 。不過別擔(dān)心，那些 commit 還在 feature 分支里。

最后，用 git checkout 切換到新的 feature 分支，并且讓你最近所有的工作成果都完好無損。

及時分支，省去繁瑣

場景: 你在 master 分支的基礎(chǔ)上創(chuàng)建了 feature 分支，但 master 分支已經(jīng)滯后于 origin/master 很多。現(xiàn)在 master 分支已經(jīng)和 origin/master 同步，你希望在 feature 上的提交是從現(xiàn)在開始，而不是也從滯后很多的地方開始。

方法: git checkout feature 和 git rebase master

原理: 要達(dá)到這個效果，你本來可以通過 git reset (不加 --hard, 這樣可以在磁盤上保留修改) 和 git checkout -b new branch name> 然后再重新提交修改，不過這樣做的話，你就會失去提交歷史。我們有更好的辦法。

git rebase master 會做如下的事情：

     首先它會找到你當(dāng)前 check out 的分支和 master 分支的共同祖先。

     然后它 reset 當(dāng)前  check out 的分支到那個共同祖先，在一個臨時保存區(qū)存放所有之前的提交。

     然后它把當(dāng)前 check out 的分支提到 master 的末尾部分，并從臨時保存區(qū)重新把存放的 commit 提交到 master 分支的最后一個 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，只要在編輯器里刪除那一行就行了。如果你不再需要項(xiàng)目里的那幾個錯誤的提交，你可以刪除上例中的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 合并到一起：

修復(fù)更早期的 commit

場景: 你在一個更早期的 commit 里忘記了加入一個文件，如果更早的 commit 能包含這個忘記的文件就太棒了。你還沒有 push，但這個 commit 不是最近的，所以你沒法用 commit --amend.

方法: git commit --squash SHA of the earlier commit> 和 git rebase --autosquash -i even earlier SHA>

原理: git commit --squash 會創(chuàng)建一個新的 commit ，它帶有一個 commit 消息，類似于 squash! Earlier commit。 (你也可以手工創(chuàng)建一個帶有類似 commit 消息的 commit，但是 commit --squash 可以幫你省下輸入的工作。)

如果你不想被提示為新合并的 commit 輸入一條新的 commit 消息，你也可以利用 git commit --fixup 。在這個情況下，你很可能會用commit --fixup ，因?yàn)槟阒皇窍Ｍ?rebase 的時候使用早期 commit 的 commit 消息。

rebase --autosquash -i  會激活一個交互式的 rebase 編輯器，但是編輯器打開的時候，在 commit 清單里任何 squash! 和 fixup! 的 commit 都已經(jīng)配對到目標(biāo) commit 上了，如下所示：

在使用 --squash 和 --fixup 的時候，你可能不記得想要修正的 commit 的 SHA 了— 只記得它是前面第 1 個或第 5 個 commit。你會發(fā)現(xiàn) Git 的 ^ 和 ~ 操作符特別好用。HEAD^ 是 HEAD 的前一個 commit。 HEAD~4 是 HEAD 往前第 4 個 – 或者一起算，倒數(shù)第 5 個 commit。

停止追蹤一個文件

場景: 你偶然把 application.log 加到代碼庫里了，現(xiàn)在每次你運(yùn)行應(yīng)用，Git 都會報告在 application.log 里有未提交的修改。你把 *.login 放到了 .gitignore 文件里，可文件還是在代碼庫里 — 你怎么才能告訴 Git “撤銷” 對這個文件的追蹤呢？

方法: git rm --cached application.log

原理: 雖然 .gitignore 會阻止 Git 追蹤文件的修改，甚至不關(guān)注文件是否存在，但這只是針對那些以前從來沒有追蹤過的文件。一旦有個文件被加入并提交了，Git 就會持續(xù)關(guān)注該文件的改變。類似地，如果你利用 git add -f 來強(qiáng)制或覆蓋了 .gitignore， Git 還會持續(xù)追蹤改變的情況。之后你就不必用-f  來添加這個文件了。

如果你希望從 Git 的追蹤對象中刪除那個本應(yīng)忽略的文件， git rm --cached 會從追蹤對象中刪除它，但讓文件在磁盤上保持原封不動。因?yàn)楝F(xiàn)在它已經(jīng)被忽略了，你在  git status 里就不會再看見這個文件，也不會再偶然提交該文件的修改了。

總結(jié)

以上這就是如何在 Git 里撤銷任何操作的方法，希望本文的內(nèi)容對大家的學(xué)習(xí)或者工作能帶來一定的幫助，如果有疑問大家可以留言交流。