使用倒圈恢復丟失的投入

本文是“高級Git”系列的一部分。請務必關注我們的Twitter 或註冊我們的新聞通訊，以便了解未來的文章！

Git 的“Reflog”功能鮮為人知，但卻非常實用。有些人稱之為“安全網”，而我更喜歡將其視為Git 的“日記”。這是因為Git 使用它來記錄HEAD 指針的每一次移動（即每次提交、合併、變基、挑選、重置等）。 Git 會將您的操作記錄在Reflog 中，這使其成為寶貴的日誌簿，也是出現問題時的良好起點。

在本“高級Git”系列的最後一部分，我將解釋git log和git reflog之間的區別，並向您展示如何使用Reflog 恢復已刪除的提交和已刪除的分支。

高級Git 系列：

• 第一部分：在Git 中創建完美的提交
• 第二部分： Git 中的分支策略
• 第三部分：通過拉取請求實現更好的協作
• 第四部分：合併衝突
• 第五部分：變基與合併
• 第六部分：交互式變基
• 第七部分：在Git 中挑選提交
• 第八部分：使用Reflog 恢復丟失的提交（您現在在這裡！ ）

git log或git reflog ：有什麼區別？

在之前的文章中，我建議您使用git log命令檢查之前的事件並查看您的提交歷史記錄，這就是它的確切作用。它顯示當前HEAD 及其祖先，即其父級、下一父級等等。日誌通過遞歸打印每個提交的父級一直追溯到提交歷史記錄的開頭。它是存儲庫的一部分，這意味著在您推送、獲取或拉取後它會被複製。

另一方面， git reflog是私有的與工作區相關的記錄。它不會遍歷祖先列表。相反，它顯示HEAD 在過去指向的所有提交的有序列表。這就是為什麼您可以將其視為某種“撤消歷史記錄”，就像您在文字處理器、文本編輯器等中看到的那樣。

此本地記錄在技術上不是存儲庫的一部分，它與提交分開存儲。 Reflog 是.git/logs/refs/heads/中的一個文件，它跟踪每個分支的本地提交。 Git 的日記通常會在90 天后被清理（這是默認設置），但您可以輕鬆調整Reflog 的過期日期。要將天數更改為180，只需鍵入以下命令：

 $ git config gc.reflogExpire 180.days.ago

或者，您可以決定您的Reflog 永不過期：

 $ git config gc.reflogExpire never

提示：請記住，Git 區分存儲庫的配置文件（ .git/config ）、全局用戶配置（ $HOME/.gitconfig ）和系統範圍設置（ /etc/gitconfig ）。要調整用戶或系統的Reflog 過期日期，請向上面顯示的命令添加--system或--global參數。

足夠的理論背景——讓我向您展示如何使用git reflog來糾正錯誤。

恢復已刪除的提交

想像一下以下場景：查看提交歷史記錄後，您決定刪除最後兩次提交。您勇敢地執行了git reset ，兩次提交從提交歷史記錄中消失了……一段時間後，您注意到這是一個錯誤。您剛剛丟失了寶貴的更改並開始恐慌！

您真的必須從頭開始嗎？不必。換句話說：保持冷靜並使用git reflog ！

因此，讓我們弄亂事情並在現實生活中犯這個錯誤。下一張圖片顯示了我們在Tower（一個圖形化Git 客戶端）中的原始提交歷史記錄：

我們想刪除兩次提交，並將“更改關於和印記的標題”提交（ID：2b504bee）設為我們master 分支上的最後一次修訂。我們只需將哈希ID 複製到剪貼板，然後在命令行中使用git reset並輸入該哈希值：

 $ git reset --hard 2b504bee

瞧！提交消失了。現在，讓我們假設這是一個錯誤，並查看Reflog 以恢復丟失的數據。鍵入git reflog以在您的終端中查看日記：

您會注意到所有條目都是按時間順序排列的。這意味著：最新的提交位於頂部。而且，如果您仔細觀察，您會注意到幾分鐘前最頂部的致命git reset操作。

日記似乎有效——這是個好消息。因此，讓我們使用它來撤消最後一次操作並恢復重置命令之前的狀態。像以前一樣，將哈希ID（在此特定示例中為e5b19e4）複製到剪貼板。您可以再次使用git reset ，這完全有效。但在這種情況下，我將基於舊狀態創建一個新分支：

 $ git branch happy-ending e5b19e4

讓我們再次看看我們的圖形化Git 客戶端：

如您所見，已創建名為happy-ending 的新分支，其中包含我們之前刪除的提交——太棒了，什麼都沒丟失！

讓我們看另一個例子，並使用Reflog 來恢復整個分支。

恢復已刪除的分支

下一個示例類似於我們的第一個場景：我們將刪除某些內容——這次是整個分支。也許您的客戶或團隊負責人告訴您要刪除一個功能分支，也許這是您自己清理的想法。更糟糕的是，一個提交（圖片中的C3）不包含在任何其他分支中，因此您肯定要丟失數據：

讓我們實際執行此操作，然後稍後恢復分支：

在您可以刪除feature/login分支之前，您需要離開它。 （如屏幕截圖所示，它是當前HEAD 分支，您不能在Git 中刪除HEAD 分支。）因此，我們將切換分支（到master），然後我們將刪除feature/login ：

好的……現在讓我們假設我們的客戶或團隊負責人改變了主意。畢竟需要feature/login分支（包括其提交）。我們該怎麼辦？

讓我們看看Git 的日記：

 $ git reflog
776f8ca (HEAD -> master) HEAD@{0}: checkout: moving from feature/login to master
b1c249b (feature/login) HEAD@{1}: checkout: moving from master to feature/login
[...]

事實證明我們再次幸運。最後一條條目顯示了我們從feature/login切換到master 的情況。讓我們嘗試返回到之前的狀態，並將哈希ID b1c249b 複製到剪貼板。接下來，我們將基於所需狀態創建一個名為feature/login的分支：

 $ git branch feature/login b1c249b
$ git branch -vv
  feature/login b1c249b Change Imprint page title
* master 776f8ca Change about title and delete error page

太好了——分支從死亡中恢復過來，還包括我們認為丟失的寶貴提交：

如果您在像Tower 這樣的桌面GUI 中使用Git，您可以像文本編輯器或文字處理器在您輸入錯誤時一樣，只需按CMD Z即可撤消您的最後一次操作。

保持冷靜並保持跟踪

Git 的Reflog 可以成為真正的救星！如您所見，從墳墓中取出丟失的提交甚至整個分支非常容易。您需要做的就是在Reflog 中找到正確的哈希ID——其餘部分是小菜一碟。

如果您想深入了解高級Git 工具，請隨時查看我的（免費！）“高級Git 工具包”：它是一系列關於分支策略、交互式變基、Reflog、子模塊等等主題的簡短視頻的集合。

這是我們在CSS-Tricks 上的“高級Git”系列的最後一部分。我希望您喜歡這些文章。快樂黑客！

高級Git 系列：

• 第一部分：在Git 中創建完美的提交
• 第二部分： Git 中的分支策略
• 第三部分：通過拉取請求實現更好的協作
• 第四部分：合併衝突
• 第五部分：變基與合併
• 第六部分：交互式變基
• 第七部分：在Git 中挑選提交
• 第八部分：使用Reflog 恢復丟失的提交（您現在在這裡！ ）

以上是使用倒圈恢復丟失的投入的詳細內容。更多資訊請關注PHP中文網其他相關文章！