[[336268]]

雖然 merging 和 rebasing 在 git 中相似時(shí)，但他們提供不同的功能。為了讓你的歷史盡可能的干凈和完整，你應(yīng)該知道以下幾點(diǎn)。

git rebase 命令已 神奇的 Git voodoo 而聞名，初學(xué)者應(yīng)該遠(yuǎn)離它，但它實(shí)際上可以讓開發(fā)團(tuán)隊(duì)在使用時(shí)更加輕松。在本章中，我們將 把 git rebase 和與之有關(guān)聯(lián)的 git merge 命令相比較 ，并在典型的 Git 工作流 中重新定位，識(shí)別其所有潛在的機(jī)會(huì)。

概述

首先要明白關(guān)于 git rebase 的事情是它像 git merge 一樣解決相同的問題。git rebase 和 git merge 一樣都是被設(shè)計(jì)用于從一個(gè)分支獲取并合并到當(dāng)前分支，但是他們采取不同的工作方式。

考慮一下，當(dāng)你開始在 一個(gè)專用的分支上開發(fā)新特性，與此同時(shí)另一個(gè)團(tuán)隊(duì)成員用新的提交來更新了 master 分支時(shí)，會(huì)發(fā)生什么呢?這會(huì)導(dǎo)致分叉的歷史記錄，對(duì)于這個(gè)問題，使用 Git 作為協(xié)同工具的任何人來說都應(yīng)該很熟悉。

 

 

現(xiàn)在，假設(shè)你在工作時(shí)在 master 上的新提交與新特性相關(guān)。為了將新提交合并到你的 feature 分支上，你有兩種選擇：merging 或者 rebasing。

Merge 選項(xiàng)

最簡(jiǎn)單的選項(xiàng)是使用以下命令將 master 分支合并到 feature 分支：

git checkout feature 
git merge master 

或者，你可以簡(jiǎn)化成一句：

git merge master feature 

這將在 feature 分支上創(chuàng)建一個(gè)新 “ 合并提交 ” ，并把兩個(gè)分支的歷史聯(lián)系在一起。分支結(jié)構(gòu)顯示如下：

 

 

Merging 之所以好是因?yàn)樗且粋€(gè)不可逆的操作。在任何情況下，現(xiàn)有分支不能被更改。這避免了所有 rebasing 的潛在陷阱(詳見下文)。

另一方面，這也意味著每次需要合并上游更改時(shí)， feature 分支都將有一個(gè)額外的 merge 提交產(chǎn)生。如果 master 非常活躍，這可能破壞你全部的 feature 分支的歷史。使用高級(jí)的 git log 選項(xiàng)來減緩這個(gè)問題是有可能的，也讓其他開發(fā)人員很難理解這個(gè)項(xiàng)目的歷史記錄。

Rebase 選項(xiàng)

作為 merging 的一個(gè)替代品，你可以使用以下命令將 feature 分支合并到 master 分支：

git checkout feature 
git rebase master 

這將整個(gè) feature 分支從 master 分支的頂端開始，有效地將所有新的提交合并到主分支中。但是，并不是使用合并提交，而是通過為每個(gè)在原始分支上的提交創(chuàng)建全新的提交來重寫項(xiàng)目歷史。

 

 

rebasing 最主要的益處是你將獲得一個(gè)十分干凈整潔的項(xiàng)目歷史。首先，它通過 git merge 排除多余的 merge 提交需求;其次，正如你在上圖所看到的那樣，rebasing 也會(huì)產(chǎn)生完美線性的項(xiàng)目歷史記錄—你可以順著 feature 一直到項(xiàng)目的起始位置而沒有任何分支。可以方便的使用 git log ，git bisect 和 gitk 追蹤提交記錄。

但是，對(duì)于新的提交歷史有兩點(diǎn)需要權(quán)衡：安全性和可追溯性。如果你不遵循 Rebasing 的黃金法則，為你的協(xié)作工作流重寫項(xiàng)目歷史可能會(huì)成為潛在的災(zāi)難。另外，不重要的是，rebasing 會(huì)丟失合并提交所提供的上下文—你不能看到何時(shí)合并到 feature 分支中的上游變化。

交互式的 Rebasing

當(dāng)他們移動(dòng)到新的分支上，交互式合并給你機(jī)會(huì)來修改提交。自從它提供完全控制整個(gè)分支的提交歷史之后，它比自動(dòng)合并更強(qiáng)大。具有代表性的，在合并一個(gè) feature 分支到 master 時(shí)，它是被用來清除錯(cuò)誤的歷史。

要開始一個(gè)交互式的重基會(huì)話，請(qǐng)將 i 選項(xiàng)傳遞給 git rebase 命令:

git checkout feature 
git rebase -i master 

這將打開一個(gè)文本編輯器列出所有要被移動(dòng)的提交：

pick 33d5b7a Message for commit #1 
pick 9480b3d Message for commit #2 
pick 5c67e61 Message for commit #3 

此列表準(zhǔn)確定義了執(zhí)行 rebase 后分支的外觀。通過改變 pick 命令或調(diào)整條目順序來改變分支的提交歷史，你可以讓分支看起來像任何你想要的樣子。舉例說，如果第二次提交是為了修復(fù)第一次提交中的一個(gè)小問題，你可以使用 fixup 命令把他們簡(jiǎn)化成一個(gè)簡(jiǎn)單的命令：

pick 33d5b7a Message for commit #1 
fixup 9480b3d Message for commit #2 
pick 5c67e61 Message for commit #3 

當(dāng)你保存并關(guān)閉文件時(shí)，Git 將根據(jù)你的指令來執(zhí)行 rebase ，從而產(chǎn)生如下所示的項(xiàng)目歷史記錄：

 

 

像這樣排除不重要的提交使你的特性歷史相當(dāng)易懂。這一點(diǎn)是 git merge 無法比擬的。

Rebasing 的黃金規(guī)則

一旦你明白什么是 rebasing ，最重要的事情是學(xué)習(xí)什么時(shí)候不用它。 git rebase 的黃金法則是永遠(yuǎn)不要在公有分支上使用它。

舉例說，想象一下如果你將 master 分支合并到 feature 分支上會(huì)發(fā)生什么：

 

 

rebase 操作將 master 中所有提交移動(dòng)到 feature 的頭部，但問題是這一切都發(fā)生在你的倉(cāng)庫(kù)中。其他開發(fā)者依然在原來的 master 分支上繼續(xù)工作。自從 rebasing 產(chǎn)生了全新的提交，Git 將會(huì)認(rèn)為你的 master 分支的歷史記錄與其他人的歷史記錄不同。

使兩個(gè) master 分支 同步的唯一方法是將他們合并到一起，導(dǎo)致出現(xiàn)一個(gè)額外的合并操作和兩組都包含相同改變(最原始的那個(gè)，和那些來自你重新建立的分支)的提交。不用說，這是一個(gè)非常混亂的場(chǎng)景。

因此，在你運(yùn)行 git rebase 之前，一定要問自己，“還有其他人在看這個(gè)分支嗎?”，如果回答是肯定的，那么把你的手從鍵盤上拿開并開始考慮讓你的改變沒有破壞性(例如， git revert 命令)。否則，你可以隨心所欲地重寫歷史。

Force-Pushing

如果你嘗試將合并的 master 分支推送到遠(yuǎn)程庫(kù)中，Git 將防止你這樣做，因?yàn)樗c遠(yuǎn)程 master 分支有沖突。但是，你可以通過傳遞 --force 標(biāo)志來強(qiáng)制推送，就像這樣：

# Be very careful with this command! 
git push --force 

該操作會(huì)將遠(yuǎn)程倉(cāng)庫(kù)的 master 分支替換為 rebase 過的 master 分支，這會(huì)給團(tuán)隊(duì)的其他成員帶來困擾。因此，當(dāng)你確切的知道你要做什么的時(shí)候，才要非常小心的使用這些命令。

推送一個(gè)私有新特性分支到遠(yuǎn)程倉(cāng)庫(kù)(例如，用于備份)。這就好像是說，“哎呦，我不想推送 feature 分支的原始版本，拿當(dāng)前的版本替換吧。”再?gòu)?qiáng)調(diào)一次，沒有人在 feature 分支的原始版本中工作是很重要的。

工作流演練

Rebasing 能夠根據(jù)團(tuán)隊(duì)的需要或多或少的被合并到你現(xiàn)存的 Git 工作流 中。在這個(gè)選項(xiàng)中，我們將檢查 rebasing 提供在不同階段的 feature 分支開發(fā)的好處。

在任何工作流中，首先第一步是利用 git rebase 為每一個(gè) feature 創(chuàng)建一個(gè)專用的分支。這給你必要分支結(jié)構(gòu)來安全使用 rebasing ：

 

 

本地清除

最好的方法之一是合并 rebasing 到你的 工作流 以此來清理本地正在進(jìn)行的 feature 分支。通過定期的執(zhí)行一個(gè)交互式的 rebase ，你可以確保每一個(gè)在你的 feature 分支中的提交是集中且有意義的。這將讓你編寫你自己的代碼而不需要在獨(dú)立提交中擔(dān)心破壞它—你可以在事后修復(fù)它。

當(dāng)調(diào)用 git rebase ，對(duì)于新的分支你有兩個(gè)選項(xiàng)：feature 父類分支(舉例說，master 分支)，或者在你的 feature 分支中較早的提交。我們查看了在 交互式的 Rebasing 章節(jié)中首個(gè)選項(xiàng)的示例 。當(dāng)你僅僅需要修復(fù)最新提交時(shí)，后者的選擇最好。舉例說，交互式 rebase 的最后3次提交顯示如下：

git checkout feature 
git rebase -i HEAD~3 

通過指定 HEAD~3 作為新的基礎(chǔ)，事實(shí)上你并沒有移動(dòng)分支—你只是交互式的重寫了接下來的3次提交。請(qǐng)注意，這不會(huì)將上游更改合并到 feature 分支。

 

 

如果你想使用這個(gè)方法重寫整個(gè) feature， git merge-base 命令對(duì)于找到 feature 分支的原始起始點(diǎn)非常有用。以下返回原始起始點(diǎn)的提交 ID ，然后傳遞給 git rebase ：

git merge-base feature master 

交互式 rebasing 的作用在于當(dāng)他僅僅影響本地分支時(shí)，它是一個(gè) 引進(jìn) git rebase 到工作流中的好方式。其他開發(fā)人員唯一能看到的是你最后提交的成果，這應(yīng)該是一個(gè)簡(jiǎn)單且易于理解的 feature 分支歷史記錄。

但是在剛開始，這僅僅只為私有 feature 分支工作。如果你借助相同 feature 分支與其他開發(fā)者協(xié)作，分支是共有的，你也不被允許重寫它的歷史記錄。

沒有 git merge 之外的其他選擇時(shí)可以使用交互式 rebase 來清除本地提交。

合并上游更改到 Feature 中

在開篇章節(jié)中，我們知道了 feature 分支如何使用 git merge 或 git rebase 合并 master 分支的上游提交。當(dāng) rebasing 通過移動(dòng)你的 feature 分支到 master 分支的頭部來創(chuàng)建一個(gè)線性歷史時(shí)，Merging 是一個(gè)用于保護(hù)你倉(cāng)庫(kù)的整個(gè)歷史記錄的安全選項(xiàng)。

git rebase 的作用與本地清除相似(能夠同時(shí)被執(zhí)行)，但是在此過程中，它合并了 master 的上游提交。

牢記，遠(yuǎn)程分支取代 master 分支是完全合法的。這發(fā)生在其他開發(fā)者在同一個(gè) feature 分支上協(xié)作時(shí)和你需要合并他們的更改到你的倉(cāng)庫(kù)中時(shí)。

舉例說明，如果你和一個(gè)名為 John 的開發(fā)人員添加了對(duì) feature 分支的提交，從 John 的倉(cāng)庫(kù)中獲取遠(yuǎn)程 feature 分支后，你的倉(cāng)庫(kù)看起來像如下所示：

 

 

你可以用與 master 分支集成上游更改相同的方法來解決這個(gè)分叉：或者你本地的 feature 分支與 john/feature 分支合并，或者 rebase 你本地 feature 分支到 john/feature 分支的頭部。

 

 

upload successful

請(qǐng)注意，任何事情在未更改之前，rebase 不能違反 Rebasing 的黃金法則 ，因?yàn)?feature 僅僅移動(dòng)了本地提交。這就好像是在說，“將我的更改添加到 John 已經(jīng)完成了的操作中。” 在大多數(shù)情況下，這比通過合并提交與遠(yuǎn)程分支同步更為直觀。

默認(rèn)情況下， git pull 命令執(zhí)行合并，但是你可以強(qiáng)制通過使用 rebase 的 --rebase 選項(xiàng)整合遠(yuǎn)程分支。

使用 Pull 請(qǐng)求檢驗(yàn) feature 分支

如果你使用 Pull 請(qǐng)求作為代碼的審計(jì)過程，創(chuàng)建的 pull 請(qǐng)求之后，你需要避免使用 git rebase 。一旦你發(fā)出 pull 請(qǐng)求，其他開發(fā)人員就能看到你的提交，這就意味著它是一個(gè)公有分支。重寫它的歷史記錄將使 Git 和你的隊(duì)友無法追蹤到任何添加到 feature 分支上的后續(xù)提交。

任何來自其他開發(fā)者的更改需要使用 git merge 取代 git rebase 來被合并。

為此，在提交你的 pull 請(qǐng)求之前，使用交互式 rebase 清理你的代碼，通常是一個(gè)好主意。

整合認(rèn)可的 feature

在 feature 分支被你的團(tuán)隊(duì)認(rèn)可之后，在使用 git merge 整合 feature 分支到主代碼庫(kù)之前，你有一個(gè) rebasing feature 分支到 master 分支的選項(xiàng)。

合并上游更改到 feature 分支是一個(gè)類似的情況，但是，自從你不被允許在 master 中重寫提交，你最后不得不使用 git merge 來整合 feature 分支。然而，通過在合并之前執(zhí)行 rebase 確保 merge 將快速進(jìn)行，形成完美的線性歷史。這也給了你在 pull 請(qǐng)求期間將任何后續(xù)提交塞入到 feature 分支中的機(jī)會(huì)。

 

 

如果你對(duì) git rebase 感到不太舒服，你可以在臨時(shí)分支中一直執(zhí)行 rebase。那樣，如果你一不小心搞砸了你的 feature 分支歷史記錄，你可以多次檢查原始分支。例如：

git checkout feature 
git checkout -b temporary-branch 
git rebase -i master 
# [Clean up the history] 
git checkout master 
git merge temporary-branch 

總結(jié)

在你開始 rebasing 你的分支之前，這是所有你真正需要知道：如果您想要一個(gè)沒有不必要的干凈的合并提交的線性歷史記錄，你應(yīng)該爭(zhēng)取 git rebase 代替 git merge 整合來自另一個(gè)分支的改變。

另一方面，如果你想保存你項(xiàng)目的完整歷史并且避免重寫公有提交的風(fēng)險(xiǎn)，你可以堅(jiān)持使用 git merge 。任何一個(gè)選項(xiàng)都是完全有效的，至少現(xiàn)在你是有選擇性的利用 git rebase 的好處。

本文作者：Tim Pettersen， 翻譯：Queena

原文鏈接：https://dzone.com/articles/merging-vs-rebasing

版權(quán)歸作者所有，轉(zhuǎn)載請(qǐng)注明作者、原文、譯者等出處信息