用三行程式碼使你的git提交記錄變乾淨

前言

筆者最近在主導一個專案的架構遷移工作，由於遷移專案的歷史包袱較重，人員合作較多，在遷移過程中免不了進行多分支、多次commit的情況，時間一長，git的提交記錄便混亂不堪，隨便截一個圖形化的git提交歷史給大家感受一下。

各種分支瘋狂打架宛如後宮爭寵的妃子們，之所以會出現這種情況，主要還是因為濫用git merge命令並且不考慮後續的理解成本導致的。如今在大廠工作的程式設計師們，頻繁接受變更的需求，一旦一開始考慮不周到，就一定會出現了大量無意義的commit log，加上「敏捷」理念的推廣，產品的快速迭代上線變成了核心指標，這些無意義的commit log便被「下次再處理」，久而久之就混亂不堪了。

而我們在看一些開源倉庫時，會發現他們的commit記錄十分整潔，其實這並不是社群的程式設計師能力更強，而是因為他們沒有KPI大棒的鞭笞，在提交程式碼前會花時間整理自己的commit log。而這就是本文的主角了——「Git Rebase」。

git rebase和git merge

git rebase，中文翻譯為「變基」，通常用於分支合併。既然提到了分支合併，那就一定離不開git merge這個命令。

相信每個新手程式設計師剛進入職場的時候，都會聽到「xxx你把這個分支merge一下」這樣的話。那麼問題來了，假如你有6個程式設計師一起工作， 你就會有6個程式設計師的分支， 如果你使用merge, 你的程式碼歷史樹就會有六個branch跟這個主的branch交織在一起。

上圖是 git merge 操作的流程示意圖，Merge命令會保留所有commit的歷史時間。每個人對程式碼的提交是各式各樣的。儘管這些時間對於程式本身並沒有任何意義。但是merge的命令初衷就是為了保留這些時間不被修改。於是也就形成了以merge時間為基準的網狀歷史結構。每個分支上都會繼續保留各自的程式碼記錄，主分支上只保留merge的歷史記錄。子分支隨時都有可能被刪除。子分子刪除以後，你能夠看到的記錄也就是，merge某branch到某branch上了。這個歷史記錄描述基本上是沒有意義的。

而 git rebase 中文翻譯為「變基」，變得這個基指的是基準。如何理解這個基準呢？我們看一下下圖。

我們可以看到經過變基後的feature分支的基準分支發生了變化，變成了最新的master。這就是所謂的「變基」。

通過上面的兩張圖可以很明顯的發現，這兩種合併分支的方式最大的區別在於，merge後的分支，會保留兩個分支的操作記錄，這在git commit log 樹中會以交叉的形式儲存。而rebase後的分支會基於最新的master分支，從而不會形成分叉，自始至終都是一條幹淨的直線。

關於 git rebase 和 git merge 的詳細用法不在本文的介紹範圍內，詳情可以參考網際網路上的其他資料。

在變基過程中，我們通常需要進行commit的修改，而這也為我們整理git記錄提供了一個可選方案。

保持最近的幾條記錄整潔

假設我們有一個倉庫，我在這個倉庫裡執行了4次提交，通過 git reflog 命令檢視提交記錄如下。

如果我們想將Commit-3、Commit-2和Commit-1的提交合併成一次提交（假設某次提交至改了一些pom檔案），我們可以直接執行下面的命令

git rebase -i HEAD~3

-i 指的是 --interactive ，HEAD~3 指的是最近三次commit。

當然我們也可以直接指定最新的一個想保留的 Commit的ID，在上面的例子中就是Commit-0的ID，因此我們也可以寫成

git rebase -i d2b9b78

執行該命令後，我們會進入到這麼如下一個介面：

這個介面是一個Vim介面，我們可以在這個介面中檢視、編輯變更記錄。有關Vim的操作，可以看我之前寫的文章和錄製的視訊

在看前三行之前，我們先來看一下第5行的命令加深一下我們對git rebase的認識。

翻譯過來就是，將d2b9b78..0e65e22這幾個分支變基到d2b9b78這個分支，也就是將Commit-3/2/1/0這幾次變更合併到Commit-0上。

回到前面三行，這三行表示的是我們需要操作的三個 Commit，每行最前面的是對該 Commit 操作的 Command。而每個命令指的是什麼，命令列裡都已經詳細的告訴我們了。

• pick：使用該commit
• squash：使用該 Commit，但會被合併到前一個 Commit 當中
• fixup：就像 squash 那樣，但會拋棄這個 Commit 的 Commit message

因此我們可以直接改成下面這樣

這裡使用fixup，而不是squash的主要原因是squash會讓你再輸入一遍commit的log，圖省事的話，可以無腦選擇fixup模式。

然後執行:wq退出vim編輯器，我們可以看到控制檯已經輸出Successful了。

這個時候我們再來看下log 記錄，執行git log --oneline

於是最近三次的提交記錄就被合併成一條提交記錄了。

保持中間某些記錄整潔

那如果不是最後的幾個commit合併，而是中間連續的幾個Commit記錄，可以用上述方法整理合並嗎？答案是可以的，只不過需要注意一下。

我們重新建立一個新的倉庫

如果這次我們想將"third commit"和"second commit"合併為一個提交，其實和上面的方式一樣，我們只需執行git rebase -i HEAD~3，然後將中間的提交改成fixup/squash模式即可，如下圖所示：

之所以是HEAD~3，是因為我們要做的變更是基於first commit做的，因此我們也可以寫成git rebase -i a1f3929

我們來看下更改完的commit log，如下圖所示：

是不是就幹掉了third commit了。

三行程式碼讓git提交記錄保持整潔

上面我們都是在原生的git倉庫中進行的commit記錄整理，但是在實際的開發過程中，我們基本上都是寫完就直接push到遠端倉庫了，那應該如何讓遠端的開發分支也保持記錄的整潔呢？

第一種做法是在push程式碼前就做在本地整理好自己的程式碼，但是這種做法並不適用於那種本地無法部署，需要部署到遠端環境才能偵錯的場景。

這時我們只需要執行git push -f命令，將自己的修改同步到遠端分支即可。

-f是force強制的意思，之所以要強制推播是因為本地分支的變更和遠端分支出現了分歧，需要用原生的變更覆蓋遠端的。

而遠端分支更新後，如果其他人也在這條分支上更改的話，還需要執行一個git pull命令來同步遠端分支。

這裡我們來總結下讓git提交記錄保持整潔的三行程式碼。

git rebase -i xxx
git push -f
git pull

❗️❗️❗️Tips：由於rebase和push -f是有些危險的操作，因此只建議在自己的分支上執行哦。

推薦學習：《》