#前言

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

#概念

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

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

#Merge

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

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

這會在feature分支中創建一個新的“merge commit”，它將兩個分支的歷史聯系在一起，為你生成如下所示的分支結構：

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

#Rebase

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

git checkout feature
git rebase master

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

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

這使得它比命令git log，git bisect和gitk更容易瀏覽項目。但是，對這個原始的提交歷史記錄有兩個權衡：安全性和可追溯性。如果你不遵循rebase的黃金法則，重寫項目歷史記錄可能會對你的協作工作流程造成災難性后果。其次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

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

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

保存并關閉文件時，Git將根據你的指令執行rebase，從而產生如下所示的項目歷史記錄：

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

rebase的黃金法則

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

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

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

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

強制推

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

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

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

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

本地清理

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

調用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分支的原始基。以下內容返回原始基礎的提交ID，然后你可以將其傳遞給

git rebase：
git merge-base feature master

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

#總結

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

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