我的目標是重溫從舊馬車原來的改變承諾（其中，至今已回復），但由于很多事情都改變了對我的在回購的HEAD worktree那些古老的改變，解決這些問題，并提交一個新的更好的承諾SANS問題。
一千次提交前（一個月前），我提交了一個更改。
一百次提交前（一周前），有人在提交中發現了一個微妙但不可接受的問題，以便快速解除對那個人的阻止，我恢復了提交（git revert hash......就像一個魅力）。
沖刺已經過去，現在在我的 repo 中的 HEAD，我想重新打開原始提交中已恢復的更改，以便我可以梳理更改并找出發現問題的根本原因.
將一千次提交前的提交“重新打開”到我的本地作業樹中的好方法是什么？（所以git status會在我的作業樹中修改。）
更糟糕的情況是git checkout在另一個倉庫中并排提交舊的提交并進行手動差異（例如，vi -d current/foo.cpp ancient/foo.cpp）并手動復制差異。聽起來很乏味，而且出現人工錯誤的可能性更高。
會有一些沖突，但它們會相對微不足道，例如固定的錯別字或空格更改。
我不想按原樣重新提交古老的提交，因為它需要仔細檢查和修復。
uj5u.com熱心網友回復：
我建議在您的日志歷史記錄中找到還原提交的哈希值，然后<commit_hash>您可以
git revert --no-commit <commitHash>
# or the shorter
git revert -n <commitHash>
...這會將原始提交的更改帶入您的作業樹，而無需實際提交，這使您可以測驗、撰寫更多代碼，然后在您準備好時提交。
uj5u.com熱心網友回復：
您已經有了一個可行的解決方案，但我認為擴展該答案并突出您問題中的特定點會很有價值：
我不想按原樣重新提交古老的提交，因為它需要仔細檢查和修復。
意識到 Git希望您進行提交很重要；Git喜歡提交，你也應該這樣做！（我在這里只是半開玩笑。）傾向于提交的原因是，一旦提交，您就鎖定了該更改（僅在您的機器本地），如果您決定不這樣做，將來可以輕松取回使用它，但稍后改變主意。所以我建議將這句話中的心態調整為類似于：
我不希望我的最終版本按原樣保留古老的提交，因為它需要仔細檢查和修復。
這里的細微差別是你處于黑客模式，你還不知道最終版本是什么樣子。因此，我建議你做承諾古提交的是（解決沖突之后）。然后你可以修改那個提交，或者添加一個帶有修復的新提交，然后將這兩個提交壓縮成一個提交。最終結果與您一開始沒有“提交”原始提交（使用--no-commit選項）相同，但如果需要，這樣可以更輕松地將嘗試撤回起點。
因此，我建議的解決方案是，如果您從 HEAD 開始（在新分支中或在同一分支上），則其中任何一個都將具有相同的結果：
- 還原還原提交。
- 櫻桃挑選被還原的原始提交。
此時，您可能會遇到沖突。我的建議是解決它們，然后--continue恢復或挑選來創建新的提交。現在您可以破解修復程式，并可能將該修復程式放入新的提交中（或修改之前的提交）。經過更多測驗和調整后，您可以再次修改或使用最終調整進行第三次提交。滿意后，如果您希望將多個提交作為一個提交到共享存盤庫，請將這 3 個提交壓縮為一個并將其推出。
顯然這只是個人喜好。如果您想違背 Git 的原則并限制進行本地提交，當然可以。該--no-commit選項存在，并且可用于cherry-pick和revert命令。但該--no-commit選項存在的主要原因是當您恢復或挑選一系列的多個提交時，您希望將它們放在一起成為一個提交。（如果沒有該選項，您必須創建多個提交，然后自己手動將它們壓縮為一個，這樣效率更高。）對于您的特定用例，我不推薦--no-commit這里。也許一個好的經驗法則可能是：
--no-commit當您確切地知道以后要進行什么更改，并且打算在運行命令后不久提交更改時，請使用該選項。
深思熟慮...
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/332848.html
標籤：混帐 git-revert