7.7 Git 工具 - 重置揭密
重置揭密
在繼續(xù)了解更專業(yè)的工具前涩金，我們先討論一下?reset?與?checkout硕蛹。 在你初次遇到的 Git 命令中粘拾，這兩個(gè)是最讓人困惑的。 它們能做很多事情福压，所以看起來我們很難真正地理解并恰當(dāng)?shù)剡\(yùn)用它們仿村。 針對(duì)這一點(diǎn)锐朴，我們先來做一個(gè)簡(jiǎn)單的比喻。
三棵樹
理解?reset?和?checkout?的最簡(jiǎn)方法蔼囊，就是以 Git 的思維框架（將其作為內(nèi)容管理器）來管理三棵不同的樹焚志。 “樹” 在我們這里的實(shí)際意思是 “文件的集合”，而不是指特定的數(shù)據(jù)結(jié)構(gòu)畏鼓。 （在某些情況下索引看起來并不像一棵樹酱酬，不過我們現(xiàn)在的目的是用簡(jiǎn)單的方式思考它。）
Git 作為一個(gè)系統(tǒng)云矫，是以它的一般操作來管理并操縱這三棵樹的：
HEAD
HEAD 是當(dāng)前分支引用的指針膳沽，它總是指向該分支上的最后一次提交。 這表示 HEAD 將是下一次提交的父結(jié)點(diǎn)让禀。 通常挑社，理解 HEAD 的最簡(jiǎn)方式，就是將它看做?你的上一次提交?的快照巡揍。
其實(shí)痛阻，查看快照的樣子很容易。 下例就顯示了 HEAD 快照實(shí)際的目錄列表腮敌，以及其中每個(gè)文件的 SHA-1 校驗(yàn)和：
$ git cat-file -p HEAD
tree cfda3bf379e4f8dba8717dee55aab78aef7f4daf
author Scott Chacon? 1301511835 -0700
committer Scott Chacon? 1301511835 -0700
initial commit
$ git ls-tree -r HEAD
100644 blob a906cb2a4a904a152...? README
100644 blob 8f94139338f9404f2...? Rakefile
040000 tree 99f1a6d12cb4b6f19...? lib
cat-file?與?ls-tree?是底層命令阱当，它們一般用于底層工作，在日常工作中并不使用缀皱。不過它們能幫助我們了解到底發(fā)生了什么斗这。
索引
索引是你的?預(yù)期的下一次提交动猬。 我們也會(huì)將這個(gè)概念引用為 Git 的 “暫存區(qū)域”啤斗，這就是當(dāng)你運(yùn)行?git commit?時(shí) Git 看起來的樣子。
Git 將上一次檢出到工作目錄中的所有文件填充到索引區(qū)赁咙，它們看起來就像最初被檢出時(shí)的樣子钮莲。 之后你會(huì)將其中一些文件替換為新版本，接著通過?git commit?將它們轉(zhuǎn)換為樹來用作新的提交彼水。
$ git ls-files -s
100644 a906cb2a4a904a152e80877d4088654daad0c859 0 README
100644 8f94139338f9404f26296befa88755fc2598c289 0 Rakefile
100644 47c6340d6459e05787f644c2447d2595f5d3a54b 0 lib/simplegit.rb
再說一次崔拥，我們?cè)谶@里又用到了?ls-files?這個(gè)幕后的命令，它會(huì)顯示出索引當(dāng)前的樣子凤覆。
確切來說链瓦，索引并非技術(shù)上的樹結(jié)構(gòu)，它其實(shí)是以扁平的清單實(shí)現(xiàn)的。不過對(duì)我們而言慈俯，把它當(dāng)做樹就夠了渤刃。
工作目錄
最后，你就有了自己的工作目錄贴膘。 另外兩棵樹以一種高效但并不直觀的方式卖子，將它們的內(nèi)容存儲(chǔ)在?.git文件夾中。 工作目錄會(huì)將它們解包為實(shí)際的文件以便編輯刑峡。 你可以把工作目錄當(dāng)做?沙盒洋闽。在你將修改提交到暫存區(qū)并記錄到歷史之前，可以隨意更改突梦。
$ tree
.
├── README
├── Rakefile
└── lib
? ? └── simplegit.rb
1 directory, 3 files
工作流程
Git 主要的目的是通過操縱這三棵樹來以更加連續(xù)的狀態(tài)記錄項(xiàng)目的快照诫舅。
讓我們來可視化這個(gè)過程：假設(shè)我們進(jìn)入到一個(gè)新目錄，其中有一個(gè)文件宫患。 我們稱其為該文件的?v1?版本骚勘，將它標(biāo)記為藍(lán)色。 現(xiàn)在運(yùn)行?git init撮奏，這會(huì)創(chuàng)建一個(gè) Git 倉(cāng)庫(kù)俏讹，其中的 HEAD 引用指向未創(chuàng)建的分支（master?還不存在）。
此時(shí)畜吊，只有工作目錄有內(nèi)容泽疆。
現(xiàn)在我們想要提交這個(gè)文件，所以用?git add?來獲取工作目錄中的內(nèi)容玲献，并將其復(fù)制到索引中殉疼。
接著運(yùn)行?git commit，它會(huì)取得索引中的內(nèi)容并將它保存為一個(gè)永久的快照捌年，然后創(chuàng)建一個(gè)指向該快照的提交對(duì)象瓢娜，最后更新?master?來指向本次提交。
此時(shí)如果我們運(yùn)行?git status礼预，會(huì)發(fā)現(xiàn)沒有任何改動(dòng)眠砾，因?yàn)楝F(xiàn)在三棵樹完全相同。
現(xiàn)在我們想要對(duì)文件進(jìn)行修改然后提交它托酸。 我們將會(huì)經(jīng)歷同樣的過程褒颈；首先在工作目錄中修改文件。 我們稱其為該文件的?v2?版本励堡，并將它標(biāo)記為紅色谷丸。
如果現(xiàn)在運(yùn)行?git status，我們會(huì)看到文件顯示在 “Changes not staged for commit,” 下面并被標(biāo)記為紅色应结，因?yàn)樵摋l目在索引與工作目錄之間存在不同刨疼。 接著我們運(yùn)行?git add?來將它暫存到索引中。
此時(shí)，由于索引和 HEAD 不同揩慕，若運(yùn)行?git status?的話就會(huì)看到 “Changes to be committed” 下的該文件變?yōu)榫G色 ——也就是說游两，現(xiàn)在預(yù)期的下一次提交與上一次提交不同。 最后漩绵，我們運(yùn)行?git commit?來完成提交贱案。
現(xiàn)在運(yùn)行?git status?會(huì)沒有輸出，因?yàn)槿脴溆肿兊孟嗤恕?/p>
切換分支或克隆的過程也類似止吐。 當(dāng)檢出一個(gè)分支時(shí)宝踪，它會(huì)修改?HEAD?指向新的分支引用，將?索引?填充為該次提交的快照碍扔，然后將?索引?的內(nèi)容復(fù)制到?工作目錄?中瘩燥。
重置的作用
在以下情景中觀察?reset?命令會(huì)更有意義。
為了演示這些例子不同，假設(shè)我們?cè)俅涡薷牧?file.txt?文件并第三次提交它厉膀。 現(xiàn)在的歷史看起來是這樣的：
讓我們跟著?reset?看看它都做了什么。 它以一種簡(jiǎn)單可預(yù)見的方式直接操縱這三棵樹二拐。 它做了三個(gè)基本操作服鹅。
第 1 步：移動(dòng) HEAD
reset?做的第一件事是移動(dòng) HEAD 的指向。 這與改變 HEAD 自身不同（checkout?所做的）百新；reset移動(dòng) HEAD 指向的分支企软。 這意味著如果 HEAD 設(shè)置為?master?分支（例如，你正在?master?分支上）饭望，運(yùn)行?git reset 9e5e64a?將會(huì)使?master?指向?9e5e64a仗哨。
無論你調(diào)用了何種形式的帶有一個(gè)提交的?reset，它首先都會(huì)嘗試這樣做铅辞。 使用?reset --soft厌漂，它將僅僅停在那兒。
現(xiàn)在看一眼上圖斟珊，理解一下發(fā)生的事情：它本質(zhì)上是撤銷了上一次?git commit?命令苇倡。 當(dāng)你在運(yùn)行?git commit?時(shí)，Git 會(huì)創(chuàng)建一個(gè)新的提交倍宾，并移動(dòng) HEAD 所指向的分支來使其指向該提交雏节。 當(dāng)你將它?reset?回?HEAD~（HEAD 的父結(jié)點(diǎn)）時(shí)胜嗓，其實(shí)就是把該分支移動(dòng)回原來的位置高职，而不會(huì)改變索引和工作目錄。 現(xiàn)在你可以更新索引并再次運(yùn)行?git commit?來完成?git commit --amend?所要做的事情了（見?修改最后一次提交）辞州。
第 2 步：更新索引（--mixed）
注意怔锌，如果你現(xiàn)在運(yùn)行?git status?的話，就會(huì)看到新的 HEAD 和以綠色標(biāo)出的它和索引之間的區(qū)別。
接下來埃元，reset?會(huì)用 HEAD 指向的當(dāng)前快照的內(nèi)容來更新索引涝涤。
如果指定?--mixed?選項(xiàng)，reset?將會(huì)在這時(shí)停止岛杀。 這也是默認(rèn)行為阔拳，所以如果沒有指定任何選項(xiàng)（在本例中只是?git reset HEAD~），這就是命令將會(huì)停止的地方类嗤。
現(xiàn)在再看一眼上圖糊肠，理解一下發(fā)生的事情：它依然會(huì)撤銷一上次?提交，但還會(huì)?取消暫存?所有的東西遗锣。 于是货裹，我們回滾到了所有?git add?和?git commit?的命令執(zhí)行之前。
第 3 步：更新工作目錄（--hard）
reset?要做的的第三件事情就是讓工作目錄看起來像索引精偿。 如果使用?--hard?選項(xiàng)弧圆，它將會(huì)繼續(xù)這一步。
現(xiàn)在讓我們回想一下剛才發(fā)生的事情笔咽。 你撤銷了最后的提交搔预、git add?和?git commit?命令以及工作目錄中的所有工作。
必須注意叶组，--hard?標(biāo)記是?reset?命令唯一的危險(xiǎn)用法斯撮，它也是 Git 會(huì)真正地銷毀數(shù)據(jù)的僅有的幾個(gè)操作之一。 其他任何形式的?reset?調(diào)用都可以輕松撤消扶叉，但是?--hard?選項(xiàng)不能勿锅，因?yàn)樗鼜?qiáng)制覆蓋了工作目錄中的文件。 在這種特殊情況下枣氧，我們的 Git 數(shù)據(jù)庫(kù)中的一個(gè)提交內(nèi)還留有該文件的?v3?版本溢十，我們可以通過?reflog?來找回它。但是若該文件還未提交达吞，Git 仍會(huì)覆蓋它從而導(dǎo)致無法恢復(fù)张弛。
回顧
reset?命令會(huì)以特定的順序重寫這三棵樹，在你指定以下選項(xiàng)時(shí)停止：
移動(dòng) HEAD 分支的指向?（若指定了?--soft酪劫，則到此停止）
使索引看起來像 HEAD?（若未指定?--hard吞鸭，則到此停止）
使工作目錄看起來像索引
通過路徑來重置
前面講述了?reset?基本形式的行為，不過你還可以給它提供一個(gè)作用路徑覆糟。 若指定了一個(gè)路徑刻剥，reset將會(huì)跳過第 1 步，并且將它的作用范圍限定為指定的文件或文件集合滩字。 這樣做自然有它的道理造虏，因?yàn)?HEAD 只是一個(gè)指針御吞，你無法讓它同時(shí)指向兩個(gè)提交中各自的一部分。 不過索引和工作目錄?可以部分更新漓藕，所以重置會(huì)繼續(xù)進(jìn)行第 2陶珠、3 步。
現(xiàn)在享钞，假如我們運(yùn)行?git reset file.txt?（這其實(shí)是?git reset --mixed HEAD file.txt?的簡(jiǎn)寫形式揍诽，因?yàn)槟慵葲]有指定一個(gè)提交的 SHA-1 或分支，也沒有指定?--soft?或?--hard）栗竖，它會(huì)：
移動(dòng) HEAD 分支的指向?（已跳過）
讓索引看起來像 HEAD?（到此處停止）
所以它本質(zhì)上只是將?file.txt?從 HEAD 復(fù)制到索引中寝姿。
它還有?取消暫存文件?的實(shí)際效果。 如果我們查看該命令的示意圖划滋，然后再想想?git add?所做的事饵筑，就會(huì)發(fā)現(xiàn)它們正好相反。
這就是為什么?git status?命令的輸出會(huì)建議運(yùn)行此命令來取消暫存一個(gè)文件处坪。 （查看?取消暫存的文件來了解更多根资。）
我們可以不讓 Git 從 HEAD 拉取數(shù)據(jù)，而是通過具體指定一個(gè)提交來拉取該文件的對(duì)應(yīng)版本同窘。 我們只需運(yùn)行類似于?git reset eb43bf file.txt?的命令即可玄帕。
它其實(shí)做了同樣的事情，也就是把工作目錄中的文件恢復(fù)到?v1?版本想邦，運(yùn)行?git add?添加它裤纹，然后再將它恢復(fù)到?v3?版本（只是不用真的過一遍這些步驟）。 如果我們現(xiàn)在運(yùn)行?git commit丧没，它就會(huì)記錄一條“將該文件恢復(fù)到?v1?版本”的更改鹰椒，盡管我們并未在工作目錄中真正地再次擁有它。
還有一點(diǎn)同?git add?一樣呕童，就是?reset?命令也可以接受一個(gè)?--patch?選項(xiàng)來一塊一塊地取消暫存的內(nèi)容漆际。 這樣你就可以根據(jù)選擇來取消暫存或恢復(fù)內(nèi)容了。
壓縮
我們來看看如何利用這種新的功能來做一些有趣的事情 - 壓縮提交夺饲。
假設(shè)你的一系列提交信息中有 “oops.”奸汇、“WIP” 和 “forgot this file”， 聰明的你就能使用?reset?來輕松快速地將它們壓縮成單個(gè)提交往声，也顯出你的聰明擂找。 （壓縮提交?展示了另一種方式，不過在本例中用?reset?更簡(jiǎn)單浩销。）
假設(shè)你有一個(gè)項(xiàng)目贯涎，第一次提交中有一個(gè)文件，第二次提交增加了一個(gè)新的文件并修改了第一個(gè)文件撼嗓，第三次提交再次修改了第一個(gè)文件柬采。 由于第二次提交是一個(gè)未完成的工作欢唾，因此你想要壓縮它且警。
那么可以運(yùn)行?git reset --soft HEAD~2?來將 HEAD 分支移動(dòng)到一個(gè)舊一點(diǎn)的提交上（即你想要保留的第一個(gè)提交）：
然后只需再次運(yùn)行?git commit：
現(xiàn)在你可以查看可到達(dá)的歷史粉捻，即將會(huì)推送的歷史，現(xiàn)在看起來有個(gè) v1 版?file-a.txt?的提交斑芜，接著第二個(gè)提交將?file-a.txt?修改成了 v3 版并增加了?file-b.txt肩刃。 包含 v2 版本的文件已經(jīng)不在歷史中了。
檢出
最后杏头，你大概還想知道?checkout?和?reset?之間的區(qū)別盈包。 和?reset?一樣，checkout?也操縱三棵樹醇王，不過它有一點(diǎn)不同呢燥，這取決于你是否傳給該命令一個(gè)文件路徑。
不帶路徑
運(yùn)行?git checkout [branch]?與運(yùn)行?git reset --hard [branch]?非常相似寓娩，它會(huì)更新所有三棵樹使其看起來像?[branch]叛氨，不過有兩點(diǎn)重要的區(qū)別。
首先不同于?reset --hard棘伴，checkout?對(duì)工作目錄是安全的寞埠，它會(huì)通過檢查來確保不會(huì)將已更改的文件弄丟。 其實(shí)它還更聰明一些焊夸。它會(huì)在工作目錄中先試著簡(jiǎn)單合并一下仁连，這樣所有_還未修改過的_文件都會(huì)被更新。 而?reset --hard?則會(huì)不做檢查就全面地替換所有東西阱穗。
第二個(gè)重要的區(qū)別是如何更新 HEAD饭冬。?reset?會(huì)移動(dòng) HEAD 分支的指向，而?checkout?只會(huì)移動(dòng) HEAD 自身來指向另一個(gè)分支揪阶。
例如伍伤，假設(shè)我們有?master?和?develop?分支，它們分別指向不同的提交遣钳；我們現(xiàn)在在?develop?上（所以 HEAD 指向它）扰魂。 如果我們運(yùn)行?git reset master，那么?develop?自身現(xiàn)在會(huì)和?master?指向同一個(gè)提交蕴茴。 而如果我們運(yùn)行?git checkout master?的話劝评，develop?不會(huì)移動(dòng)，HEAD 自身會(huì)移動(dòng)倦淀。 現(xiàn)在 HEAD 將會(huì)指向?master蒋畜。
所以，雖然在這兩種情況下我們都移動(dòng) HEAD 使其指向了提交 A撞叽，但_做法_是非常不同的姻成。?reset?會(huì)移動(dòng) HEAD 分支的指向插龄，而?checkout?則移動(dòng) HEAD 自身。
帶路徑
運(yùn)行?checkout?的另一種方式就是指定一個(gè)文件路徑科展，這會(huì)像?reset?一樣不會(huì)移動(dòng) HEAD均牢。 它就像?git reset [branch] file?那樣用該次提交中的那個(gè)文件來更新索引，但是它也會(huì)覆蓋工作目錄中對(duì)應(yīng)的文件才睹。 它就像是?git reset --hard [branch] file（如果?reset?允許你這樣運(yùn)行的話）- 這樣對(duì)工作目錄并不安全徘跪，它也不會(huì)移動(dòng) HEAD。
此外琅攘，同?git reset?和?git add?一樣垮庐，checkout?也接受一個(gè)?--patch?選項(xiàng)，允許你根據(jù)選擇一塊一塊地恢復(fù)文件內(nèi)容坞琴。
總結(jié)
希望你現(xiàn)在熟悉并理解了?reset?命令哨查，不過關(guān)于它和?checkout?之間的區(qū)別，你可能還是會(huì)有點(diǎn)困惑剧辐，畢竟不太可能記住不同調(diào)用的所有規(guī)則寒亥。
下面的速查表列出了命令對(duì)樹的影響。 “HEAD” 一列中的 “REF” 表示該命令移動(dòng)了 HEAD 指向的分支引用浙于，而`‘HEAD’' 則表示只移動(dòng)了 HEAD 自身护盈。 特別注意?WD Safe??一列 - 如果它標(biāo)記為?NO，那么運(yùn)行該命令之前請(qǐng)考慮一下羞酗。
