查看提交列表和版本差異

云效合并請求的提交改動頁面，提供了提交列表和版本差異兩個視圖，為評審人提供全面的視角去了解代碼改動過程：

下文具體介紹兩個視圖代表的意義。

通過 “提交列表” 快速了解最新改動，進(jìn)行全量評審

提交歷史是閱讀和追溯代碼改動的方式之一。假設(shè)在實現(xiàn)某個特性 feature-x 時計劃的提交步驟如下：

commit-4: Implementation & Test cases 提交 //針對feature進(jìn)行實現(xiàn)，并添加對應(yīng)測試用例
   |
commit-3: Refactor-B 提交 //發(fā)現(xiàn)需要進(jìn)行簡單重構(gòu)，優(yōu)化 function-f 實現(xiàn)邏輯
   |
commit-2: Refactor-A 提交 //發(fā)現(xiàn)需要進(jìn)行簡單重構(gòu)，抽取公共方法便于復(fù)用
   |
commit-1: Cleanup 提交 //發(fā)現(xiàn)我們要改動的文件，存在格式化問題，將文件進(jìn)行格式化

針對以上實現(xiàn)路徑對代碼進(jìn)行了對應(yīng)的設(shè)計和實現(xiàn)，可以通過 git log adf3e902..HEAD 命令在終端查看提交歷史：

commit 47c53b7ae262fe5a40906884ae9c0c993035c085 (HEAD -> feature-x)
Author: tenglong.tl <tenglong***@email.com>
Date:   Tue Sep 26 09:56:47 2023 +0800

    feat: implement feature-x and related test cases
    
    Signed-off-by: tenglong.tl <tenglong***@emailc.com>

commit 0b5c42b2bf252069931f724a74f2f0301e7dd8a3
Author: tenglong.tl <tenglong***@email.com>
Date:   Mon Sep 25 19:46:09 2023 +0800

    refactor: optimize f() to be shorter and simpler
    
    Signed-off-by: tenglong.tl <tenglong***@email.com>

commit 4f80f46afb585497ef3f6e0ecdafde1c4d11c273
Author: tenglong.tl <tenglong***@email.com>
Date:   Mon Sep 25 19:40:57 2023 +0800

    refactor: extract common func to reuse in future
    
    Signed-off-by: tenglong.tl <tenglong***@email.com>

commit f613e9882a4cb91f87dff215b2d08b94139b40b2
Author: tenglong.tl <tenglong***@email.com>
Date:   Mon Sep 25 19:37:43 2023 +0800

    cleanup: fixup the format alerts in x.java
    
    Signed-off-by: tenglong.tl <tenglong***@email.com>

以上git log代表為了開發(fā)這個特性對應(yīng)的源碼組織形式，叫做提交列表。 在 git log 后附帶參數(shù)值adf3e902..HEAD，是為了過濾base之前的提交，僅僅查看新增的部分（在 Git 中稱為一種notation，"<commit1>..<commit2> 是 "^<commit1> <commit2>" 的簡寫，即 "<commit1>"之前的提交都不展示，顯示至 "<commit2>"為止的提交）。

優(yōu)秀的提交列表可以清晰地體現(xiàn)開發(fā)者對于整個特性研發(fā)的設(shè)計思考過程，更進(jìn)一步通過原子化的提交，讓評審人高效地了解特性實現(xiàn)路徑并可以逐個針對提交進(jìn)行評審。原子化也可以幫助開發(fā)者解耦工程，可以針對單個提交進(jìn)行獨立修改（延展閱讀：如何做好提交，成為有品位的工程師？），而不破壞其他的提交內(nèi)容。

建議評審者應(yīng)先關(guān)注提交列表而非直接查看文件改動。對提交本身的評審也非常重要，這是代碼評審所推薦的一種優(yōu)秀實踐。即使不在代碼評審場景，使用git log查看感興趣的提交歷史，了解開發(fā)者編程思路，也是使用頻率最高的 Git 命令之一了。

提交列表尤其適用評審人首次進(jìn)行全量評審的場景，這時評審人一般優(yōu)先關(guān)注最新版本的代碼改動，先總覽一下當(dāng)前最新版本的提交列表，往往可以讓評審工作事半功倍：

通過 “版本差異” 定位版本（Patchset）之間提交變化，進(jìn)行增量評審

提交列表可以滿足首次評審時，查看最新代碼改動的場景。但是，好的代碼是不斷迭代的，對應(yīng)代碼評審的版本（Patchset）也會不斷更新，兩個版本（Patchset）之間的提交改動可能很小，也可能因為一些原因?qū)е滦吕献兓笙鄰酵ァ?/p>

關(guān)注版本間提交的變化，可以輕松識別已經(jīng)評審過的文件內(nèi)容，而僅關(guān)注新變化的內(nèi)容，進(jìn)行增量評審，降低評審人力投入。

以上文的場景為例，評審作者創(chuàng)建一個評審的版本-1（Patchset-1）：

47c53b7 (HEAD -> feature-x) feat: implement feature-x and related test cases
0b5c42b refactor: optimize f() to be shorter and simpler
4f80f46 refactor: extract common func to reuse in future
f613e98 cleanup: fixup the format alerts in x.java

版本-1（Patchset-1）中包含了 4 個提交，隨后評審者-A針對提交feat: implement feature-x and related test cases給了評審意見：“該提交內(nèi)容較多，原子化程度不高，建議拆分，從而更好的使用 git-bisect 命令進(jìn)行提交的CI覆蓋，方便后續(xù)評審和修改。”

于是作者更新代碼，提交了評審版本-2（Patchset-2），保持其他三個提交不變，同時將提交 1 feat: implement feature-x and related test cases拆分為 4 個新提交：

此時，執(zhí)行git log adf3e90..HEAD --oneline命令顯示最新的提交列表變成如下形式：

3add20b controller: REST mapping and ACL implementation
7525c08 service: feat-X implementations and test cases
06a5e4f dao: implements DAO interface
054ea6d api: REST interface declaration
0b5c42b refactor: optimize f() to be shorter and simpler
4f80f46 refactor: extract common func to reuse in future
f613e98 cleanup: fixup the format alerts in x.java

將評審版本-2（Patchset-2）與評審版本-1（Patchset-1）的提交列表進(jìn)行對比，可以看到：

• f613e98 4f80f46 0b5c42b3個提交保持不變。

• 刪除了提交47c53b7。

• 新增了 054ea6d 06a5e4f 7525c08 3add20b4 個提交。

對于評審者-A來說，保持不變的 3 個提交已經(jīng)在評審版本-1（Patchset-1）中完成過評審，沒必要再看一遍。僅需針對刪除提交和新產(chǎn)生的 4 個提交進(jìn)行再次評審。

這種評審的實踐，對于評審效率的提升無疑是巨大的。一方面，評審者關(guān)注的改動范圍得到的縮小，而不用每次都通過瀏覽全量的文件改動來識別差異。另一方面，可以更加了解評審作者的編碼思路和設(shè)計，幫助評審人給出更加正確和準(zhǔn)確的評審建議。

識別提交變化，僅通過提交列表比較困難。例如對于中間提交進(jìn)行修改，重新優(yōu)化提交說明，或是編排提交列表順序。要想識別出這些改動，需要借助于 range-diff 命令，即通過git range-diff adf3e90..47c53b7 adf3e90..3add20b來查看版本范圍（提交列表）之間的差異，提交改動在終端的展示如下：

其中：

• =代表提交未變化。

• <代表提交刪除。

• >代表提交新增。

• !代表提交發(fā)生變化（例如：元數(shù)據(jù)例如提交說明、作者信息等，或者文件改動）。

對應(yīng)在云效代碼評審中，也可以通過版本差異視圖在頁面直接查看 range-diff 的內(nèi)容：

總結(jié)

提交列表更適用于首次評審場景，對所有提交進(jìn)行全量評審。而版本差異適合多次補丁迭代評審的場景，可以幫助評審者有效控制評審范圍，其更加關(guān)注版本PatchSet的變化，進(jìn)行增量評審。

當(dāng)把提交的內(nèi)容盡量解耦，同時讓每個提交具備原子性之后，頻繁發(fā)送最新的版本補丁（基于補丁（patchset）的評審工作流）就變成了極為優(yōu)秀的實踐方式。一方面，可以及時的告知評審者們工作的進(jìn)展，另一方面評審者每次評審的內(nèi)容也可以基于遞進(jìn)式的方式，變得更加可控和高效。

假設(shè)如果在周五下班前一口氣發(fā)送了包含上文示例中的4個提交補丁 A，結(jié)果卻在代碼評審時被告知 API 接口的設(shè)計存在問題，那么最壞的情況下需要修改 1~4 的全部4個提交，可是明明在周一的時候就完成了 API 接口的設(shè)計。最后，對于評審作者，優(yōu)秀的提交也能更加及時地獲取各方評審者的反饋，讓問題得到提前修正的機會，形成低成本的正向評審循環(huán)。

云效代碼評審秉承推廣優(yōu)秀實踐的原則，在產(chǎn)品能力上支撐“小步快跑”的評審模式，期望幫助開發(fā)者簡化繁重的代碼評審工作，實現(xiàn)高效協(xié)同。