用三行代碼使你的git提交記錄變干凈

前言

筆者最近在主導(dǎo)一個(gè)項(xiàng)目的架構(gòu)遷移工作，由于遷移項(xiàng)目的歷史包袱較重，人員合作較多，在遷移過程中免不了進(jìn)行多分支、多次commit的情況，時(shí)間一長，git的提交記錄便混亂不堪，隨便截一個(gè)圖形化的git提交歷史給大家感受一下。

各種分支瘋狂打架宛如后宮爭(zhēng)寵的妃子們，之所以會(huì)出現(xiàn)這種情況，主要還是因?yàn)闉E用git merge命令并且不考慮后續(xù)的理解成本導(dǎo)致的。如今在大廠工作的程序員們，頻繁接受變更的需求，一旦一開始考慮不周到，就一定會(huì)出現(xiàn)了大量無意義的commit log，加上“敏捷”理念的推廣，產(chǎn)品的快速迭代上線變成了核心指標(biāo)，這些無意義的commit log便被“下次再處理”，久而久之就混亂不堪了。

而我們?cè)诳匆恍╅_源倉庫時(shí)，會(huì)發(fā)現(xiàn)他們的commit記錄十分整潔，其實(shí)這并不是社區(qū)的程序員能力更強(qiáng)，而是因?yàn)樗麄儧]有KPI大棒的鞭笞，在提交代碼前會(huì)花時(shí)間整理自己的commit log。而這就是本文的主角了——“Git Rebase”。

git rebase和git merge

git rebase，中文翻譯為“變基”，通常用于分支合并。既然提到了分支合并，那就一定離不開git merge這個(gè)命令。

相信每個(gè)新手程序員剛進(jìn)入職場(chǎng)的時(shí)候，都會(huì)聽到“xxx你把這個(gè)分支merge一下”這樣的話。那么問題來了，假如你有6個(gè)程序員一起工作， 你就會(huì)有6個(gè)程序員的分支， 如果你使用merge, 你的代碼歷史樹就會(huì)有六個(gè)branch跟這個(gè)主的branch交織在一起。

上圖是 git merge 操作的流程示意圖，Merge命令會(huì)保留所有commit的歷史時(shí)間。每個(gè)人對(duì)代碼的提交是各式各樣的。盡管這些時(shí)間對(duì)于程序本身并沒有任何意義。但是merge的命令初衷就是為了保留這些時(shí)間不被修改。于是也就形成了以merge時(shí)間為基準(zhǔn)的網(wǎng)狀歷史結(jié)構(gòu)。每個(gè)分支上都會(huì)繼續(xù)保留各自的代碼記錄，主分支上只保留merge的歷史記錄。子分支隨時(shí)都有可能被刪除。子分子刪除以后，你能夠看到的記錄也就是，merge某branch到某branch上了。這個(gè)歷史記錄描述基本上是沒有意義的。

而 git rebase 中文翻譯為“變基”，變得這個(gè)基指的是基準(zhǔn)。如何理解這個(gè)基準(zhǔn)呢？我們看一下下圖。

我們可以看到經(jīng)過變基后的feature分支的基準(zhǔn)分支發(fā)生了變化，變成了最新的master。這就是所謂的“變基”。

通過上面的兩張圖可以很明顯的發(fā)現(xiàn)，這兩種合并分支的方式最大的區(qū)別在于，merge后的分支，會(huì)保留兩個(gè)分支的操作記錄，這在git commit log 樹中會(huì)以交叉的形式保存。而rebase后的分支會(huì)基于最新的master分支，從而不會(huì)形成分叉，自始至終都是一條干凈的直線。

關(guān)于 git rebase 和 git merge 的詳細(xì)用法不在本文的介紹范圍內(nèi)，詳情可以參考互聯(lián)網(wǎng)上的其他資料。

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

保持最近的幾條記錄整潔

假設(shè)我們有一個(gè)倉庫，我在這個(gè)倉庫里執(zhí)行了4次提交，通過 git reflog 命令查看提交記錄如下。

如果我們想將Commit-3、Commit-2和Commit-1的提交合并成一次提交（假設(shè)某次提交至改了一些pom文件），我們可以直接執(zhí)行下面的命令

git rebase -i HEAD~3

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

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

git rebase -i d2b9b78

執(zhí)行該命令后，我們會(huì)進(jìn)入到這么如下一個(gè)界面：

這個(gè)界面是一個(gè)vim界面，我們可以在這個(gè)界面中查看、編輯變更記錄。有關(guān)Vim的操作，可以看我之前寫的文章和錄制的視頻《和Vim的初次見面》

在看前三行之前，我們先來看一下第5行的命令加深一下我們對(duì)git rebase的認(rèn)識(shí)。

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

回到前面三行，這三行表示的是我們需要操作的三個(gè) Commit，每行最前面的是對(duì)該 Commit 操作的 Command。而每個(gè)命令指的是什么，命令行里都已經(jīng)詳細(xì)的告訴我們了。

• pick：使用該commit
• squash：使用該 Commit，但會(huì)被合并到前一個(gè) Commit 當(dāng)中
• fixup：就像 squash 那樣，但會(huì)拋棄這個(gè) Commit 的 Commit message

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

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

然后執(zhí)行:wq退出vim編輯器，我們可以看到控制臺(tái)已經(jīng)輸出Successful了。

這個(gè)時(shí)候我們?cè)賮砜聪耹og 記錄，執(zhí)行g(shù)it log –oneline

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

保持中間某些記錄整潔

那如果不是最后的幾個(gè)commit合并，而是中間連續(xù)的幾個(gè)Commit記錄，可以用上述方法整理合并嗎？答案是可以的，只不過需要注意一下。

我們重新創(chuàng)建一個(gè)新的倉庫

如果這次我們想將”third commit”和”second commit”合并為一個(gè)提交，其實(shí)和上面的方式一樣，我們只需執(zhí)行g(shù)it rebase -i HEAD~3，然后將中間的提交改成fixup/squash模式即可，如下圖所示：

之所以是HEAD~3，是因?yàn)槲覀円龅淖兏腔趂irst commit做的，因此我們也可以寫成git rebase -i a1f3929

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

是不是就干掉了third commit了。

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

上面我們都是在本地的git倉庫中進(jìn)行的commit記錄整理，但是在實(shí)際的開發(fā)過程中，我們基本上都是寫完就直接push到遠(yuǎn)程倉庫了，那應(yīng)該如何讓遠(yuǎn)程的開發(fā)分支也保持記錄的整潔呢？

第一種做法是在push代碼前就做在本地整理好自己的代碼，但是這種做法并不適用于那種本地?zé)o法部署，需要部署到遠(yuǎn)程環(huán)境才能調(diào)試的場(chǎng)景。

這時(shí)我們只需要執(zhí)行g(shù)it push -f命令，將自己的修改同步到遠(yuǎn)程分支即可。

-f是force強(qiáng)制的意思，之所以要強(qiáng)制推送是因?yàn)楸镜胤种У淖兏瓦h(yuǎn)程分支出現(xiàn)了分歧，需要用本地的變更覆蓋遠(yuǎn)程的。

而遠(yuǎn)程分支更新后，如果其他人也在這條分支上更改的話，還需要執(zhí)行一個(gè)git pull命令來同步遠(yuǎn)程分支。

這里我們來總結(jié)下讓git提交記錄保持整潔的三行代碼。

git rebase -i xxx git push -f git pull

??????Tips：由于rebase和push -f是有些危險(xiǎn)的操作，因此只建議在自己的分支上執(zhí)行哦。

推薦學(xué)習(xí)：《《和Vim的初次見面》》