使用 Git 已經好幾年了，卻始終只是熟悉一些常用的操作。對于 Git Rebase 卻很少用到，直到這一次，不得不用。

一、起因

上線構建的過程中掃了一眼代碼變更，突然發現，?commit?提交竟然多達?62?次。我們來看看都提交了什么東西：

這里我們先不說?git?提交規范，就單純這么多次無用的?commit?就很讓人不舒服。可能很多人覺得無所謂，無非是多了一些提交紀錄。

然而，并非如此，你可能聽過破窗效應，編程也是如此！

二、導致問題

1.不利于代碼?review
設想一下，你要做?code review?，結果一個很小的功能，提交了?60?多次，會不會有一些崩潰？

2.會造成分支污染

你的項目充滿了無用的?commit?紀錄，如果有一天線上出現了緊急問題，你需要回滾代碼，卻發現海量的?commit?需要一條條來看。

遵循項目規范才能提高團隊協作效率，而不是隨心所欲。

三、如何合并多次提交紀錄？

基于上面所說問題，我們不難想到：每一次功能開發， 對多個 commit 進行合并處理。

這時候就需要用到?git rebase?了。這個命令沒有太難，不常用可能源于不熟悉，所以我們來通過示例學習一下。

1.我們來合并最近的 4 次提交紀錄，執行：

git rebase -i HEAD~4

2.這時候，會自動進入?vi?編輯模式：

s cacc52da add: qrcode s f072ef48 update: indexeddb hack s 4e84901a feat: add indexedDB floder s 8f33126c feat: add test2.js# Rebase 5f2452b2..8f33126c onto 5f2452b2 (4 commands) # # Commands: # p, pick = use commit # r, reword = use commit, but edit the commit message # e, edit = use commit, but stop for amending # s, squash = use commit, but meld into previous commit # f, fixup = like "squash", but discard this commit's log message # x, exec = run command (the rest of the line) using shell # d, drop = remove commit # # These lines can be re-ordered; they are executed from top to bottom. # # If you remove a line here THAT COMMIT WILL BE LOST. # # However, if you remove everything, the rebase will be aborted. #

有幾個命令需要注意一下：

• p, pick = use commit
• r, reword = use commit, but edit the commit message
• e, edit = use commit, but stop for amending
• s, squash = use commit, but meld into previous commit
• f, fixup = like “squash”, but discard this commit’s log message
• x, exec = run command (the rest of the line) using shell
• d, drop = remove commit

按照如上命令來修改你的提交紀錄：

s cacc52da add: qrcode s f072ef48 update: indexeddb hack s 4e84901a feat: add indexedDB floder p 8f33126c feat: add test2.js

3.如果保存的時候，你碰到了這個錯誤：

error: cannot 'squash' without a previous commit

注意不要合并先前提交的東西，也就是已經提交遠程分支的紀錄。

4.如果你異常退出了?vi?窗口，不要緊張：

git rebase --edit-todo

這時候會一直處在這個編輯的模式里，我們可以回去繼續編輯，修改完保存一下：

git rebase --continue

5.查看結果

git log

三次提交合并成了一次，減少了無用的提交信息。

四、Rebase 的另外一種使用場景：分支合并

1.我們先從?master?分支切出一個?dev?分支，進行開發：

git:(master) git checkout -b feature1

2.這時候，你的同事完成了一次?hotfix?，并合并入了?master?分支，此時?master?已經領先于你的?feature1?分支了：

3.恰巧，我們想要同步?master?分支的改動，首先想到了?merge?，執行：

git:(feature1) git merge master

?圖中綠色的點就是我們合并之后的結果，執行：

git:(feature1) git log

就會在記錄里發現一些?merge?的信息，但是我們覺得這樣污染了?commit?記錄，想要保持一份干凈的?commit?，怎么辦呢？這時候，?git rebase?就派上用場了。

4.讓我們來試試?git rebase?，先回退到同事?hotfix?后合并?master?的步驟：

5.使用?rebase?后來看看結果：

git:(feature1) git rebase master

這里補充一點：?rebase?做了什么操作呢？

首先，?git?會把?feature1?分支里面的每個?commit?取消掉；

其次，把上面的操作臨時保存成?patch?文件，存在?.git/rebase?目錄下；

然后，把?feature1?分支更新到最新的?master?分支；

最后，把上面保存的?patch?文件應用到?feature1?分支上；

從?commit?記錄我們可以看出來，?feature1?分支是基于?hotfix?合并后的?master?，自然而然的成為了最領先的分支，而且沒有?merge?的?commit?記錄，是不是感覺很舒服了。

6.在?rebase?的過程中，也許會出現沖突?conflict?。在這種情況，?git?會停止?rebase?并會讓你去解決沖突。在解決完沖突后，用?git add?命令去更新這些內容。

注意，你無需執行 git-commit，只要執行 continue

git rebase --continue

這樣?git?會繼續應用余下的?patch?補丁文件。

7.在任何時候，我們都可以用?--abort?參數來終止?rebase?的行動，并且分支會回到?rebase?開始前的狀態。

git rebase —abort

?

總結

以上是生活随笔為你收集整理的这一次彻底搞懂 Git Rebase的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。