git rebase與相關git merge命令比較

#前言

git rebase命令經(jīng)常被認為是Git的巫術(shù)，初學者應該遠離它，但它實際上可以讓開發(fā)團隊在使用時更加輕松。今天，我們將git rebase與相關git merge命令進行比較。

#概念

首先要理解的是git rebase和git merge解決了同樣的問題。這兩個命令都旨在將更改從一個分支集成到另一個分支 - 它們只是以不同的方式進行。試想一下當你開始在專用分支中開發(fā)新功能時另一個團隊成員以新提交更新master分支會發(fā)生什么。這會出現(xiàn)分叉歷史記錄，對于使用Git作為協(xié)作工具的任何人來說都應該很熟悉。

當合并master分支到你的feature分支時，你有兩個選擇：merge或rebase。

#Merge

最簡單最常用的是將master分支合并到feature分支中：

git checkout feature
git merge master
或者，你可以簡化為一行：
git merge master feature

這會在feature分支中創(chuàng)建一個新的“merge commit”，它將兩個分支的歷史聯(lián)系在一起，為你生成如下所示的分支結(jié)構(gòu)：

合并很好，因為它是一種非破壞性的操作?，F(xiàn)有分支結(jié)構(gòu)不會以任何方式更改。這避免了rebase的所有潛在缺陷（下面細說）。另一方面，這也意味著每次上游更改時feature都需要合并，且有無關的合并提交。如果master改動非常頻繁，這可能會嚴重污染你分支的歷史記錄。盡管可以使用高級git log選項減輕此問題的影響，但它可能使其他開發(fā)人員難以理解項目的歷史更改記錄。

#Rebase

作為merge的替代方法，你可以使用以下命令將feature分支rebase到master分支上：

git checkout feature
git rebase master

這會將整個feature分支移動到master分支的頂端，從而有效地整合了所有master的新提交。但是，rebase不是使用merge commit，而是通過為原始分支中的每個提交創(chuàng)建全新的提交來重寫項目歷史記錄。

rebase的主要好處是可以獲得更清晰的項目歷史記錄。首先，它消除了不必要的git merge產(chǎn)生的merge commit。其次，正如在上圖中所看到的，rebase也會產(chǎn)生完美線性的項目歷史記錄 - 你可以從feature分支頂端一直跟隨到項目的開始而沒有任何的分叉。

這使得它比命令git log，git bisect和gitk更容易瀏覽項目。但是，對這個原始的提交歷史記錄有兩個權(quán)衡：安全性和可追溯性。如果你不遵循rebase的黃金法則，重寫項目歷史記錄可能會對你的協(xié)作工作流程造成災難性后果。其次rebase會丟失merge commit提供的上下文 - 你無法看到上游更改何時合并到功能中。

#Interactive Rebase

Interactive rebase使你有機會在將提交移動到新分支時更改提交。這比自動rebase更強大，因為它提供了對分支提交歷史的完全控制。通常，這用于在合并特征分支到master分支之前清理雜亂的歷史記錄。要開始基于交互式會話，請將i選項傳遞給git rebase命令：

git checkout feature
git rebase -i master

這將打開一個文本編輯器，列出即將移動的所有提交：

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

列表準確給出了執(zhí)行rebase后分支的概況。通過更改pick命令和（或）重新排序，可以使分支的歷史記錄成為你想要的內(nèi)容。例如，如果第二次提交修復了第一次提交中的一個小問題，你可以使用以下fixup命令將它們壓縮為單個提交：

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

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

消除這種無意義的提交使你的歷史記錄更可讀。這是git merge無法做到的事情。

rebase的黃金法則

一旦你理解了什么是rebase，最重要的是了解什么時候不使用它。git rebase的黃金法則是永遠不要在公共分支使用它。例如，想想如果你把master分支rebase到你的feature分支會發(fā)生什么：

rebase將master所有提交移動到feature頂端。問題是這只發(fā)生在你的倉庫中。所有其他開發(fā)人員仍在使用原始版本master。由于rebase導致全新的提交，

Git會認為你的master分支的歷史與其他人的歷史不同。同步兩個master分支的唯一方法是將它們合并在一起，從而產(chǎn)生額外的合并提交和兩組包含相同更改的提交（原始提交和來自rebase分支的更改）。

這將是一個非常令人困惑的情況。因此，在你運行g(shù)it rebase之前，總是問自己，“還有其他人在用這個分支嗎？”如果答案是肯定的，那就把你的手從鍵盤上移開，考慮使用非破壞性的方式進行（例如，git revert命令）。否則，你可以隨心所欲地重寫歷史記錄。

強制推

如果你嘗試將rebase過的master分支推到遠程倉庫，Git將阻止你這樣做，因為它與遠程master分支沖突。但是，你可以通過傳遞--force標志來強制推送，如下所示:

＃這個命令要非常小心！
git push --force

這將覆蓋遠程master分支以匹配rebase過的分支，并使團隊的其他成員感到困惑。因此，只有在確切知道自己在做什么時才能非常小心地使用此命令。

工作流rebase可以根據(jù)你團隊的需要盡多地或少量地整合到你現(xiàn)有的Git工作流程中。在本節(jié)中，我們將了解rebase在功能開發(fā)的各個階段的好處。任何工作流程git rebase的第一步是為每個功能創(chuàng)建專用分支。這為你提供了必要的分支結(jié)構(gòu)，以安全地利用rebase：

本地清理

將rebase加入工作流程的最佳方法之一是清理本地正在進行的功能。通過定期執(zhí)行交互式rebase，你可以確保功能中的每個提交都具有針對性和意義。這使你可以寫代碼而無需擔心將其分解為隔離多個的提交 - 你可以在事后修復它。

調(diào)用git rebase時，有兩個基（base）選項：feature的父分支（例如master），或feature中的歷史提交。我們在Interactive Rebasing部分看到了第一個選項的示例。當你只需要修復最后幾次提交時，后一種選擇很好。例如，以下命令僅針對最后3次提交的交互式rebase。

git checkout feature
git rebase -i HEAD~3

通過指定HEAD~3為新的基，你實際上并沒有移動分支 - 你只是交互式地重寫其后的3個提交。請注意，這不會將上游更改合并到feature分支中。

如果要使用此方法重寫整個功能，git merge-base命令可用于查找feature分支的原始基。以下內(nèi)容返回原始基礎的提交ID，然后你可以將其傳遞給

git rebase：
git merge-base feature master

交互式rebase的使用是引入git rebase工作流的好方法，因為它只影響本地分支。其他開發(fā)人員唯一能看到的就是你的成品，這應該是一個簡潔易懂的分支歷史記錄。
但同樣，這僅適用于私有功能分支。如果你通過相同的分支與其他開發(fā)人員協(xié)作，則該分支是公共的，并且你能重寫其歷史記錄。

#總結(jié)

這就是你需要知道的關于rebase你的分支。如果你更喜歡提交的干凈，消除不必要合并的線性歷史記錄，那么你在繼承另一分支的更改時應該使用git rebase 而不是git merge。

另一方面，如果你想保留項目的完整歷史記錄并避免重寫公共提交的風險，你可以仍然使用git merge。這兩種選擇都是完全可以的，但至少可以選擇利用git rebase有它的好處。