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

這篇文章為大家帶來了關於git的相關知識，其中主要跟大家聊一聊怎麼讓你的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的操作，可以看我之前写的文章和录制的视频《和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是有些危险的操作，因此只建议在自己的分支上执行哦。

推荐学习：《Git视频教程》

以上是用三行程式碼讓你的git提交記錄變乾淨的詳細內容。更多資訊請關注PHP中文網其他相關文章！