一、起因
上線構建的過程中掃了一眼代碼變更，突然發現， 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 狀態是這樣的：
這是背景，接下來我們正式開始今天的內容。
分支合併
我們先在 master 分支的基礎上新建一個 dev 分支, 並做一個 commit：
> $(master) git checkout -b dev
這時候另外一個開發人員發現 master 上的代碼有一個問題，對 master 的代碼做了一個 fix，使得 master 的 head 向前推進了一步:
如果我們想將 master 的 Fix 改動應用到 dev 分支上，要如何做呢？
可以使用 merge，我們來試下：
$(dev) git merge master
merge 過後 dev 分支向前推進了一步。我們看下多出來的 commit 信息是怎樣的
dev 上 多出來的這個 commit（綠色的那個節點）, 就是我們的 merge 信息。
有時候我們並不想要 git 記錄這個 merge 信息，因爲讓 git 的歷史記錄變得很繁瑣，要如何做呢？可以使用 rebase ！
我們先回到 master 提交了 fix 之後的 git 狀態：
執行 rebase 命令：
$ (dev) git rebase master
這時候看下 git 狀態：
比較下 merge 和 rebase 之後的狀態圖，我們可以發現 master 的 fix 被接到 dev 的後面，並且沒有多出一個 merge 信息。這樣 commit 信息是不是簡潔了很多？
commit 改寫
除了用在分支的合併上， rebase 命令還能幫你修改 commit 記錄。
我們讓 dev 分支再向前推進 3 步：
╰─$ git log
提交完這 3 個 commit 之後，我們發現這 3 個 commit 屬於同一個改動類型，完全沒必要分成 3 個 commit。
那要怎麼做呢？還是可以使用 rebase
$ (dev) git rebase -i HEAD~4
執行該命令 shell 會進入交互模式（-i）
根據提示，我們將文本做如下修改(將 pick 換成 s,至於爲什麼要這樣寫，可以看 git 的提示)：
保存並退出：
現在 git 又進入瞭如下狀態，只不過綠色的那個節點包含了 4 個 commit 信息
commit 0a15d3549ee9ec61ddeb33916c452fab2ad9b991 (HEAD -> dev)
這時候再將 dev 合併進 master，commit 信息都會簡潔很多，並且也有利於 review。
總結
rebase 是一個很神奇的工具，可以幫你做一些比較特別的改動。但要注意， rebase 是會隱藏你真實的修改記錄的，所以最後呈現出來的 git 歷史並不能表現你的真實操作，這點要注意。