掌握強(qiáng)大的 Git 變基命令
當(dāng)我與別人談到 Git 時(shí)，幾乎每個(gè)人都對(duì) ??git rebase 命令?? 有強(qiáng)烈的印象，這個(gè)命令讓許多人遇到了問題，而不得不更改目錄、刪除倉庫、然后再重新克隆一個(gè)倉庫。我認(rèn)為這是因?yàn)樗麄冋`解了分支是如何工作，遇到了一個(gè)非常糟糕的默認(rèn)界面，還有一些合并沖突把事情搞得一團(tuán)糟。
怎么找不到 git squash 命令？
如果你曾在本地的倉庫提交過很多次，并希望能把這些提交都合并為一個(gè)提交，接下來，我們就來介紹能用什么 Git 命令達(dá)到這個(gè)目的。Git 稱這個(gè)概念為 “壓扁提交squash commits”。我在編寫文檔時(shí)發(fā)現(xiàn)了這個(gè)概念：我花了十幾個(gè)提交才修改好我的 Markdown 文檔，但是倉庫的維護(hù)者不想看到我的所有嘗試，以免擾亂了該項(xiàng)目的歷史，所以我被告知“需要壓扁你的提交”。
壓扁提交聽起來是一個(gè)很有用的方法。但是只有一個(gè)問題：我不知道該怎么做。作為 Git 的新手，我做了任何人會(huì)做的事情：我去查閱 ??git-squash?? 的手冊(cè)，但我立即遇到了阻礙：
我發(fā)現(xiàn)沒有一個(gè)名為 ??squash?? 的 Git 命令，而是被要求 ??運(yùn)行一個(gè)完全獨(dú)立的命令：git rebase 命令??，該命令能將我的所有提交最終合并為一個(gè)提交。
我知道我碰到一個(gè)常見的情形：已經(jīng)使用工具一段時(shí)間的人使用了行話或引用了一個(gè)概念，這個(gè)概念對(duì)他們來說是非常清楚的，但對(duì)新手來說就不能明白了。從概念上講，這個(gè)情況看起來是這樣的：
of 6 bowls of different Image colored spices, and an arrow pointing to the second image of all the spices blended into one bowl.
我這樣說是為了鼓勵(lì)你，你絕對(duì)不是第一個(gè)或最后一個(gè) 被 Git 或談?wù)?Git 的人 弄糊涂的人。你可以要求對(duì)方說明白他的意見，并幫助你應(yīng)該使用的正確命令。倉庫的維護(hù)者實(shí)際上的意思是，“使用 ??git rebase?? 命令**，將很多提交壓扁成一個(gè)提交”。
現(xiàn)在就來學(xué)習(xí) git rebase 命令吧
??git rebase?? 命令會(huì)將一個(gè)提交鏈從其第一個(gè)父級(jí)中刪除，并將其放置在另一個(gè)提交鏈的末尾，將兩個(gè)提交鏈組合成一個(gè)長鏈，而不是兩個(gè)并行鏈。我意識(shí)到這是一個(gè)很復(fù)雜的定義。
回想一下 Git 的提交是如何鏈接在一起的，你可以看到，除了初始的 ??main??（或 ??master??）分支外，任何分支都有一個(gè) 父提交parent commit 作為該鏈的 “基礎(chǔ)base”?！白兓鵵ebase” 能使另一個(gè)鏈中的最后一個(gè)提交成為指定分支的新 “基礎(chǔ)提交base commit”。
在 Git 中整合來自不同分支的修改主要有兩種方法：合并merge 以及 變基rebase，你可能更熟悉 ??git merge?? 命令。接下來，就來看看 [??git-scm.com??] 是如何解釋 ??git merge?? 和 ??git rebase?? 的差異：
Image of Git merge versus git rebase shown as numbered bubbles.
在合并示例中，它會(huì)把兩個(gè)分支的最新快照（??C3?? 和 ??C4??）以及二者最近的共同祖先（??C2??）進(jìn)行三方合并，合并的結(jié)果是生成一個(gè)新的快照（??C5??）。??experiment?? 的分支指針仍然存在，仍然指向 ??C4??。
在變基示例中，它提取在 ??C4?? 中引入的補(bǔ)丁和修改，然后在 ??C3?? 的基礎(chǔ)上應(yīng)用一次，使 ??C3?? 成為 ??C4?? 的新父級(jí)，并產(chǎn)生了一個(gè)名為 ??C4'?? 的新提交。
（LCTT 譯注：具體的命令如下：
它的原理是首先找到這兩個(gè)分支 —— 即當(dāng)前分支 ??experiment??、變基操作的目標(biāo)基底分支 ??main?? —— 的最近共同祖先 ??C2??，然后對(duì)比當(dāng)前分支相對(duì)于該祖先的歷次提交，提取相應(yīng)的修改并存為臨時(shí)文件，然后將當(dāng)前分支指向目標(biāo)基底 ??C3??，最后以此將之前另存為臨時(shí)文件的修改依序應(yīng)用。）
值得注意的是，分支指針 ??main?? 沒有移動(dòng)。要讓 Git 將指針移動(dòng)到鏈的末尾（由??experiment?? 指向），你還需要執(zhí)行合并。
（LCTT 譯注：具體的命令如下：
master 分支的快進(jìn)合并
此時(shí)，??C4'?? 指向的快照就和上面使用 ??merge?? 命令的例子中 ??C5?? 指向的快照一模一樣了。）
??git rebase?? 并不能替代 ??git merge??。??git rebase?? 是一種用于制作更清晰的歷史記錄，以與 ??git merge?? 結(jié)合使用的工具。
（LCTT 譯注：使用 ??git rebase?? 命令將提交到某一分支上的所有修改都移至另一分支上，就好像“重新播放”一樣。）
交互式變基能給你一個(gè)更友好的界面！
從命令行執(zhí)行 ??git rebase?? 命令，最可怕的地方在于它糟糕的默認(rèn)界面。運(yùn)行命令 ??git rebase <target-refr>?? 要么有效，要么會(huì)變得一團(tuán)糟，因?yàn)樗鼪]有太多的反饋或方法來確保它做你想做的事情。幸運(yùn)的是，??git rebase?? 命令和許多其他 Git 命令一樣，具有 交互模式interactive mode，你可以使用參數(shù) ??-i?? 或者 ??-interactive?? 來使用交互模式。
Image of the Git lens interactive Rebase tool in VS Code.
在使用交互式模式時(shí)，??git rebase?? 會(huì)從一個(gè)糟糕的黑框界面轉(zhuǎn)換為一個(gè)選項(xiàng)菜單，允許你選擇對(duì)正在變基的提交鏈所做的事。對(duì)于每個(gè)提交，你可以選擇：
- 選用pick：按原樣包含
- 重寫reword：重寫提交消息
- 編寫edit：在變基完成之前對(duì)提交中的文件進(jìn)行進(jìn)一步更改
- 壓扁squash：將多個(gè)提交壓縮成一個(gè)提交，保留所有提交消息
- 修理fixup：將多個(gè)提交壓縮成一個(gè)提交，但只保留最后一個(gè)提交消息
- 丟棄drop：丟棄此提交
就我個(gè)人而言，我更喜歡 ??VS Code 的開源 GitLens 擴(kuò)展?? 使用下拉選擇列表布局選項(xiàng)的方式，但 Git 允許你使用任何編輯器選擇這些選項(xiàng)。對(duì)于 Emacs 或 Vim 等純文本工具，你需要鍵入選擇，而不是從菜單中選擇，但最終結(jié)果仍然是相同的。
何時(shí)做變基
知道 何時(shí) 做變基與知道 如何 做變基同樣重要。事實(shí)上，如果你不在乎你的倉庫歷史提交消息有點(diǎn)混亂的話，那么你可以永遠(yuǎn)都不使用 ??git rebase?? 命令。但是，如果你想要更干凈的歷史提交消息，并且想要更少擾亂你的圖形視圖的提交，那么當(dāng)你使用 ??git rebase?? 命令時(shí)，有一個(gè)重要的經(jīng)驗(yàn)法則需要時(shí)刻記?。?/p>
“不要變基你存儲(chǔ)庫以外的的提交，那些提交可能是別人工作的基礎(chǔ)?！?/p>
如果你遵循該準(zhǔn)則，不會(huì)發(fā)生什么大問題的。
簡而言之，如果你讓一個(gè)本地分支來完成你的工作，變基是沒有問題的。但一旦該分支被 推送push
希望你會(huì)認(rèn)為上述內(nèi)容有助于你理解 ??git rebase?? 命令的工作原理，并能讓你更有信心地使用它。與任何 Git 命令一樣，練習(xí)是學(xué)習(xí)和理解怎么做的唯一方法。我鼓勵(lì)你勇敢地嘗試 交互式變基interactive rebase ??git rebase -i <branch name>??！
接下來學(xué)習(xí) Git cherry-pick 命令吧
大多數(shù)開發(fā)人員將修改提交到某一分支上，但是之后發(fā)現(xiàn)他們一直提交到了錯(cuò)誤的分支上。理想情況下，他們可以拿走那個(gè)提交，然后把它移到正確的分支，這正是 ??git cherry-pick?? 命令的作用。
??git cherry-pick?? 命令利用了變基單個(gè)提交的方法。這一用法非常常見，以至于有了它自己的命令。
Image of a woman picking a cherry from one tree and putting on another tree.
要使用 ??git cherry-pick??，你只需告訴 Git 你要移動(dòng)到“那個(gè)分支”的提交 ID（由 ??HEAD?? 指向）：
如果出現(xiàn)問題，你可以根據(jù) Git 提供的錯(cuò)誤消息，來進(jìn)行恢復(fù)：
讓 Git 更強(qiáng)大
??git rebase?? 命令是 Git 實(shí)用程序強(qiáng)大的地方之一。你最好在測試倉庫中先練習(xí)一下怎么使用，一旦你熟悉了它的概念和工作流程，你就可以給倉庫一個(gè)清晰歷史消息記錄了。
