?
This document uses PHP Chinese website manual Release
命名
git-reset - 將當(dāng)前 HEAD 重置為指定狀態(tài)
概要
git reset [-q] [<tree-ish>] [--] <paths>… git reset (--patch | -p) [<tree-ish>] [--] [<paths>…]git reset [--soft | --mixed [-N] | --hard | --merge | --keep] [-q] [<commit>]
描述
在第一種和第二種形式中，將 <tree-ish> 中的條目復(fù)制到索引中。在第三種形式中，將當(dāng)前分支頭（HEAD）設(shè)置為 <commit> ，可選地修改索引和工作樹以匹配。<tree-ish> / <commit> 默認(rèn)為所有形式的 HEAD 。
git reset -q -- <paths>…
該表單將所有 <paths> 的索引條目重置為它們?cè)?<tree-ish> 的狀態(tài)。（它不會(huì)影響工作樹或當(dāng)前分支。）
這意味著這git reset <paths>與git add <paths>是相反的。
在運(yùn)行git reset <paths>以更新索引條目之后，可以使用 git-checkout [1] 將索引中的內(nèi)容檢查到工作樹?；蛘撸褂?git-checkout [1] 并指定提交，您可以一次將提交中的路徑內(nèi)容復(fù)制到索引和工作樹中。
git reset (--patch | -p) <tree-ish> <paths>…
在索引和 <tree-ish> 之間的差異中交互選擇 hunk（默認(rèn)為 HEAD ）。選定的區(qū)塊與指數(shù)相反。
這意味著這git reset -p與git add -p是相反的，也就是說(shuō)，你可以用它來(lái)選擇性地重置人群。請(qǐng)參閱 git-add [1] 的“交互模式”部分了解如何操作該--patch模式。
git reset <mode>
此表單將當(dāng)前分支頭重置為 <commit> ，并可能更新索引（將其重置為 <commit> 的樹），并根據(jù) <mode> 更新工作樹。如果省略 <mode> ，則默認(rèn)為“--mixed”。<mode> 必須是以下之一：
--soft
根本不觸摸索引文件或工作樹（但將頭重置為 <commit> ，就像所有模式一樣）。這git status將使所有更改的文件“變更被提交”，就像它會(huì)這樣。
--mixed
重置索引而不是工作樹（即，保存更改的文件但未標(biāo)記為提交）并報(bào)告尚未更新的內(nèi)容。這是默認(rèn)操作。
如果-N指定，則刪除的路徑將標(biāo)記為 intent-to-add（請(qǐng)參閱 git-add [1] ）。
--hard
重置索引和工作樹。放棄自 <commit> 以來(lái)對(duì)工作樹中跟蹤文件的任何更改。
--merge
重置索引并更新工作樹中 <commit> 和 HEAD 之間不同的文件，但保留索引和工作樹之間不同的文件（即沒有添加更改的文件）。如果 <commit> 和索引之間的文件有不同的變化，則重置會(huì)中止。
換句話說(shuō)，--merge 可以做一些類似的事情git read-tree -u -m <commit>，但是會(huì)傳遞未合并的索引條目。
--keep
重置索引條目并更新工作樹中 <commit> 和 HEAD 之間不同的文件。如果 <commit> 和 HEAD 之間的文件有本地更改，則重置會(huì)中止。
如果你想撤消一個(gè)分支以外的提交，git-revert [1] 是你的朋友。
選項(xiàng)
-q --quiet
只報(bào)告錯(cuò)誤。
例子
撤消添加
$ edit (1)$ git add frotz.c filfre.c $ mailx (2)$ git reset (3)$ git pull git://info.example.com/ nitfol (4)
您正在愉快地處理某些事情，并發(fā)現(xiàn)這些文件中的更改順利進(jìn)行。當(dāng)你運(yùn)行 “git diff” 時(shí)，你不想看到它們，因?yàn)槟愦蛩阍谄渌募瞎ぷ鳎褂眠@些文件進(jìn)行更改會(huì)讓人分心。
有人讓你去拉，而這些變化聽起來(lái)值得合并。
但是，您已經(jīng)弄臟了索引（即您的索引與 HEAD 提交不匹配）。但是你知道你要做的拉不會(huì)影響 frotz.c 或 filfre.c ，所以你可以恢復(fù)這兩個(gè)文件的索引更改。工作樹的變化仍然存在。
然后你可以拉和合并，在工作樹中仍然保留 frotz.c 和 filfre.c 的變化。
撤消提交并重做
$ git commit ...$ git reset --soft HEAD^ (1)$ edit (2)$ git commit -a -c ORIG_HEAD (3)
當(dāng)你記住你剛才提交的內(nèi)容不完整，或者你拼錯(cuò)了你的提交信息，或者兩者兼而有之時(shí)，通常會(huì)這樣做。像在“重置”之前那樣使樹工作。
更正工作樹文件。
“reset”將舊頭復(fù)制到 .git / ORIG_HEAD ; 從日志消息開始重做提交。如果您不需要進(jìn)一步編輯該消息，則可以改為給 -C 選項(xiàng)。
另請(qǐng)參閱 git-commit [ - ] 的 --amend 選項(xiàng)。
撤消提交，使其成為主題分支
$ git branch topic/wip (1)$ git reset --hard HEAD~3 (2)$ git checkout topic/wip (3)
你已經(jīng)做了一些提交，但意識(shí)到他們?cè)?“master” 分支還為時(shí)尚早。您想要繼續(xù)在主題分支中打磨它們，因此請(qǐng)從當(dāng)前 HEAD 創(chuàng)建 “主題/ wip” 分支。
倒回主分支以擺脫這三個(gè)提交。
切換到 “topic / wip” 分支并繼續(xù)工作。
撤消永久提交
$ git commit ...$ git reset --hard HEAD~3 (1)
最后三個(gè)提交（ HEAD ，HEAD ^ 和 HEAD?2 ）很差，你不想再看到它們。難道不是如果你已經(jīng)給了這些提交給別人做。（有關(guān)這樣做的含義，請(qǐng)參閱 git-rebase [1] 中的“從上游重新啟動(dòng)恢復(fù)”一節(jié)。）
撤消合并或拉
$ git pull (1)Auto-merging nitfolCONFLICT (content): Merge conflict in nitfol Automatic merge failed; fix conflicts and then commit the result.$ git reset --hard (2)$ git pull . topic/branch (3)Updating from 41223... to 13134...Fast-forward $ git reset --hard ORIG_HEAD (4)
嘗試從上游更新導(dǎo)致很多沖突; 你現(xiàn)在還沒有準(zhǔn)備好花很多時(shí)間合并，所以你稍后決定這么做。
“pull” 沒有進(jìn)行合并提交，因此 “git reset --hard” 是 “git reset --hard HEAD” 的同義詞，從索引文件和工作樹中清除混亂。
將主題分支合并到當(dāng)前分支中，從而實(shí)現(xiàn)快速轉(zhuǎn)發(fā)。
但是你決定主題分支尚未準(zhǔn)備好供公眾使用?！袄被颉昂喜ⅰ笨偸菍?dāng)前分支的原始尖端留在 ORIG_HEAD 中，因此難以重置會(huì)使索引文件和工作樹返回到該狀態(tài)，并將分支的尖端重置為該提交。
撤消一個(gè)合并或拉一個(gè)不完美的工作樹內(nèi)
$ git pull (1)Auto-merging nitfol Merge made by recursive. nitfol | 20 +++++---- ...$ git reset --merge ORIG_HEAD (2)
即使你可能在你的工作樹上進(jìn)行了局部修改，當(dāng)你知道另一個(gè)分支中的變化與它們沒有重疊時(shí)，你也可以安全地說(shuō)出 “git pull” 。
在檢查合并的結(jié)果后，您可能會(huì)發(fā)現(xiàn)其他分支的變化不令人滿意。運(yùn)行 “git reset --hard ORIG_HEAD” 可以讓你回到你所在的位置，但它會(huì)放棄你不想要的本地修改?！癵it reset --merge” 保留你的本地修改。
中斷的工作流程
假設(shè)當(dāng)你處于一個(gè)大的變化中時(shí)，你被緊急修復(fù)請(qǐng)求中斷。工作樹中的文件沒有任何形狀可供提交，但需要到另一個(gè)分支進(jìn)行快速修補(bǔ)。
$ git checkout feature ;# you were working in "feature" branch and $ work work work ;# got interrupted $ git commit -a -m "snapshot WIP" (1)$ git checkout master $ fix fix fix $ git commit ;# commit with real log $ git checkout feature $ git reset --soft HEAD^ ;# go back to WIP state (2)$ git reset (3)
這個(gè)提交會(huì)被吹走，所以丟棄的日志消息是 OK 的。
這將刪除
WIP提交歷史記錄中的提交，并將您的工作樹設(shè)置為您創(chuàng)建該快照之前的狀態(tài)。此時(shí)，索引文件仍具有您所承諾的所有 WIP 更改
snapshot WIP。這會(huì)更新索引以將您的 WIP 文件顯示為未提交。
另見 git-stash [1] 。
重置索引中的單個(gè)文件
假設(shè)你已經(jīng)添加了一個(gè)文件到你的索引，但稍后決定你不想將它添加到你的提交。您可以從索引中刪除文件，同時(shí)使用 git reset 保留更改。
$ git reset -- frotz.c (1)$ git commit -m "Commit files in index" (2)$ git add frotz.c (3)
這將文件從索引中刪除，同時(shí)保留在工作目錄中。
這會(huì)提交索引中的所有其他更改。
再次將文件添加到索引。
在改變工作樹的同時(shí)放棄一些以前的提交
假設(shè)你正在處理一些事情，然后你繼續(xù)工作，然后你繼續(xù)工作多一點(diǎn)，但是現(xiàn)在你認(rèn)為你工作樹中的內(nèi)容應(yīng)該在另一個(gè)分支中，這與你以前承諾的事情沒有任何關(guān)系。您可以啟動(dòng)一個(gè)新分支并重置它，同時(shí)將更改保留在工作樹中。
$ git tag start $ git checkout -b branch1 $ edit $ git commit ... (1)$ edit $ git checkout -b branch2 (2)$ git reset --keep start (3)
這會(huì)在 branch1 中提交您的第一批編輯。
在理想的世界中，當(dāng)你創(chuàng)建并切換到 branch2 時(shí)（例如 “git checkout -b branch2 start” ），你可能意識(shí)到早期的提交不屬于新的主題，但沒有人是完美的。
但是在切換到 “branch2” 之后，您可以使用 “reset --keep” 刪除不需要的提交。
將提交拆分為一系列提交
假設(shè)您已經(jīng)創(chuàng)建了大量邏輯上單獨(dú)的更改并將它們一起提交。然后，稍后您決定將每個(gè)邏輯塊與其自己的提交關(guān)聯(lián)起來(lái)可能會(huì)更好。您可以使用 git reset 在不改變本地文件內(nèi)容的情況下回退歷史記錄，然后使用預(yù)先填充提交消息git add -p來(lái)交互式地選擇要包含到每個(gè)提交中的哪些區(qū)塊git commit -c。
$ git reset -N HEAD^ (1)$ git add -p (2)$ git diff --cached (3)$ git commit -c HEAD@{1} (4)... (5)$ git add ... (6)$ git diff --cached (7)$ git commit ... (8)首先，將歷史記錄重置為一次提交，以便刪除原始提交，但保留所有更改的工作樹。-N 確保任何添加了 HEAD 的新文件仍被標(biāo)記，以便 git add -p 可以找到它們。
接下來(lái)，我們使用 git add -p 工具交互地選擇 diff hunk 添加。這將問你關(guān)于每個(gè)差異大小順序，你可以使用簡(jiǎn)單的命令，如“是的，包括這個(gè)”，“不包括這個(gè)”，甚至是非常強(qiáng)大的“編輯”設(shè)施。
一旦滿足你想要包含的區(qū)塊，你應(yīng)該通過(guò)使用 git diff --cached 來(lái)驗(yàn)證為第一次提交準(zhǔn)備了什么。這顯示了所有已移入索引并即將提交的更改。
接下來(lái)，提交存儲(chǔ)在索引中的更改。-c 選項(xiàng)指定從第一次提交中啟動(dòng)的原始消息中預(yù)填充提交消息。這有助于避免重新輸入。HEAD @ {1} 是 HEAD 用于在原始重置提交之前進(jìn)行提交的一種特殊符號(hào)（1次更改前）。有關(guān)更多詳細(xì)信息，請(qǐng)參閱 git-reflog [1]。您也可以使用任何其他有效的提交引用。
您可以多次重復(fù)步驟2-4以將原始代碼分解為任意次數(shù)的提交。
現(xiàn)在，您已將許多更改拆分為自己的提交，并可能不再使用 git add 的修補(bǔ)模式，以便選擇所有未提交的更改。
再次檢查以確認(rèn)您已包含您想要的內(nèi)容。您可能還希望驗(yàn)證一下，git diff 不會(huì)顯示任何剩余的更改以后再提交。
最后創(chuàng)建最終提交。
討論
下表顯示了運(yùn)行時(shí)發(fā)生的情況：
git reset --option target
target根據(jù)文件的狀態(tài)使用不同的重置選項(xiàng)將 HEAD 重置為另一個(gè)提交（）。
在這些表中，A ，B ，C 和 D 是文件的一些不同狀態(tài)。例如，第一個(gè)表的第一行意味著如果文件處于工作樹狀態(tài)A ，索引狀態(tài) B ，HEAD 狀態(tài) C 和目標(biāo)狀態(tài) D ，則 “git reset - 軟目標(biāo)“ 將使文件在狀態(tài)A的工作樹中和狀態(tài)B的索引中。它將 HEAD（即，當(dāng)前分支的頂端，如果你在一個(gè)上）重置（即移動(dòng)）到 ”目標(biāo)“（其中狀態(tài)為 D 的文件）。
working index HEAD target working index HEAD ---------------------------------------------------- A B C D --soft A B D--mixed A D D--hard D D D--merge (disallowed)--keep (disallowed)
working index HEAD target working index HEAD ---------------------------------------------------- A B C C --soft A B C--mixed A C C--hard C C C--merge (disallowed)--keep A C C
working index HEAD target working index HEAD ---------------------------------------------------- B B C D --soft B B D--mixed B D D--hard D D D--merge D D D--keep (disallowed)
working index HEAD target working index HEAD ---------------------------------------------------- B B C C --soft B B C--mixed B C C--hard C C C--merge C C C--keep B C C
working index HEAD target working index HEAD ---------------------------------------------------- B C C D --soft B C D--mixed B D D--hard D D D--merge (disallowed)--keep (disallowed)
working index HEAD target working index HEAD ---------------------------------------------------- B C C C --soft B C C--mixed B C C--hard C C C--merge B C C--keep B C C
“復(fù)位 - 合并”意味著在重置沖突合并時(shí)使用。任何合并操作都可以保證合并中涉及的工作樹文件在啟動(dòng)之前不會(huì)對(duì)索引進(jìn)行本地更改，并且可以將結(jié)果寫入工作樹。所以如果我們看到索引和目標(biāo)之間以及索引和工作樹之間存在某種差異，那么這意味著我們不會(huì)從一個(gè)在發(fā)生沖突后失敗的狀態(tài)中重置。這就是為什么我們?cè)谶@種情況下不允許 - 合并選項(xiàng)。
在保留對(duì)工作樹的修改的同時(shí)，刪除當(dāng)前分支中的某些最后提交時(shí)，將使用 “reset --keep” 。如果我們要?jiǎng)h除的提交更改與我們想要保留的工作樹更改之間可能存在沖突，則不允許重置。這就是為什么如果工作樹和 HEAD 之間以及 HEAD 和目標(biāo)之間都存在變化，則不允許它。為了安全起見，當(dāng)沒有合并的條目時(shí)它也被禁止。
下表顯示了在沒有合并條目時(shí)發(fā)生的情況：
working index HEAD target working index HEAD ---------------------------------------------------- X U A B --soft (disallowed)--mixed X B B--hard B B B--merge B B B--keep (disallowed)
working index HEAD target working index HEAD ---------------------------------------------------- X U A A --soft (disallowed)--mixed X A A--hard A A A--merge A A A--keep (disallowed)
X 表示任何狀態(tài)，U 表示未合并的索引。