在Git重新設置期間如何檢出特定的提交

Question

我處於git rebase的中間。 我所依據的分支有很多更改，涉及到與我修改過的相同代碼。 我花了很多時間在基礎上工作，我快要完成了。 但是我在現在正在處理的提交中添加了一個新功能，該功能不再起作用。 我寫此功能的方式與現有功能類似，並且可以看到現有功能的功能已由我根據其改編的代碼進行了更改。

我想找到更改現有功能的提交。 我想先檢查一下最后一次提交，然后再開始編寫代碼，以確保確實更改了現有功能。 但是，當我嘗試簽出其他提交時，出現一條錯誤消息，告訴我我需要從合並的當前步驟中合並文件，並且需要首先解析當前索引。 但是，直到弄清楚現有功能的修改方式之后，我才能解析當前索引。 我該怎么辦？

Answer 1

您擁有的兩個評論（至少到目前為止）是在此處繼續前進的關鍵。

背景

暫停的暫停（出於任何原因，包括交互式重新設置“編輯”選項）將工作樹置於分離的HEAD模式。 這是一個微妙的狀態，在這里干擾HEAD設置是不明智的（其他分支或提交的git checkout會這樣做）。

由於合並沖突而暫停的rebase更加糟糕：它不僅具有斷開的HEAD模式，而且索引處於沖突狀態。 由於該指數是犯至關重要的，你可以用這個工作樹做的唯一事情是要么修復沖突，並繼續或終止底墊，把一切都回到你啟動方式。

您不想執行以下操作：您想完成重新設置基准，因為：

我花了很多時間在基礎上工作，我快要完成了。

因此，解決方案是獲得不同的工作樹。

獲取另一個工作樹

在現代Git（自Git 2.5版開始）中，有一個命令git worktree ，帶有子命令可創建一個新的工作樹。 每個工作樹都帶有自己的HEAD和自己的索引。 這意味着您可以將現有的存儲庫完整地保留在原處，並具有正在進行的rebase及其分離的HEAD和可能有沖突的索引，而只需添加一個已簽出另一個分支的新工作樹即可。

自git worktree 2.5發行以來，已經發現了許多錯誤。 在修復此相當討厭的錯誤之前，我要避免在Git 2.15左右使用過多的時間。 ^1但是 ，即使只是查看其他分支，即使Git 2.5版本也可以。

如果您的Git早於2.5，或者您對上述錯誤感到不安，則可以簡單地克隆現有存儲庫。 與添加的工作樹相比，克隆要花更多的磁盤空間和時間，但花的時間並不多，它們可以在每個版本的Git中工作。

---

¹我自己被這個小蟲子咬了。 但是，值得注意的是，如果您的對象（ git gc可能認為未引用的對象）比修剪時間（默認為14天）年輕，那是無害的。 壽命短的側面工作樹通常不會觸發這些git worktree錯誤（此錯誤和其他錯誤已固定在2.5和2.15之間）。