我在之前的文章里面不是經常叫大家拉源碼，然后看代碼提交記錄嗎。

也就是看類似于這個界面：

比如上面這個界面中，就可以看到 RedissonBaseLock.java 這個文件，由誰在什么時候進行過變更，以及變更對應的 commit 信息是什么。

這樣就能很直觀的看到文件的演變過程。

那么問題就來了，有好幾個同學都問過我這個問題：怎么在 idea 里面查看 git 提交記錄呢？這個界面是藏在哪里的呢，我的 idea 里面怎么沒有呢？

好的，是我疏忽了，我先入為主的認為這個大家應該都知道是怎么來的。

但是確實是有一些同學是不太清楚的，那我這篇文章就給大家分享一下我通過這個東西看源碼的一點點小技巧，希望能幫助到你。

怎么搞出來？

那么怎么把這個視圖搞出來呢？

首先，你本地得有一個 git.exe。

這個玩意怎么來的，就不用我說了吧，如果連這個都沒有，說明你之前還沒有接觸過 git，那就是另外一回事兒了，不在本文討論范圍內。趕緊去安裝一個 git，然后學學 git 的用法啥的。

我個人的習慣是先用 gitbash，也就是這個玩意，從 github 上 clone 一個項目下來：

比如我就用之前寫文章的 Redssion 做演示吧，你也可以隨便找一個自己感興趣的開源項目。

執行下面命令把項目下載下來：

git clone https://github.com/redisson/redisson.git

下載完成之后，打開你的 idea，導入我們剛剛下載的項目。

然后隨便打開一個文件，點擊右鍵，看看有沒有 Git 這個選項：

如果順利的話，你點擊 ShowHistory 之后，就能看到這個窗口了：

如果不順利，說明你的 git 配置有問題。

在 idea 的 Settings 里面進行對應的設置：

設置完成之后，可以點擊旁邊的 test 按鈕，如果有彈窗告訴你對應的版本號，那就說明配置成功了：

總之，只要能調出 Version Control 標簽頁或者有的高版本里面就叫做 git，就代表配置成功了。

怎么看？

不管是在工作中還是寫文章的時候，我一般在 idea 里面只是看提交記錄，我不會用 idea 里面的 git 去做提交代碼的動作。

其實 idea 里面拉取代碼，提交代碼什么的可視化頁面做的很好，但是我還是比較喜歡直接在 gitbash 里面敲命令，也沒有什么特別的原因，只是這樣顯得逼格高而已。

那么，到底怎么去看呢？

以我之前寫的 Redisson 文章為例。

主要是圍繞著 RedissonLock.java 這個類在寫，我是怎么知道這個類的呢？

其實自己帶著問題去 debug 也肯定能定位到這個類，但是需要一點時間。

我以前就是搭完環境之后，就開始瘋狂的寫案例 debug 了。

現在我學聰明了，環境搞定之后，先去 github 的 issues 里面拿著關鍵詞去搜一下。

比如我的關鍵詞就是死鎖：

但是我強烈建議你別用中文搜索，用英文，deadLock：

這樣能搜出來的信息就很多，剩下的就是你一個個點開，看看是不是和自己遇到的問題一樣，或者相似。

這個過程會花一點點時間，但是絕對比你一頭扎進源碼里面找答案快的多。

比如，上面的截圖中，最后一個叫 Deadlock after Redis timeout 的 issue，就是我想要找的東西：

在這個里面給出了復現的代碼，涉及的版本，以及預期的結果和實際的表現。

比如說我找到這個鏈接之后，對我而言就是找到了一個測試用例，同時他告訴了我一個命令：

CLIENT PAUSE 5000

在這之前，我是不知道這個命令的。我還一直在想，我做 Demo 復現的時候，應該怎么去模擬 Redis 執行命令超時的現象呢？

我當時能想到的一些方案就是 bigkey，或者灌很多數據進去，然后我執行 keys * 命令，再或者搞個 save 命令，這樣來模擬 Redis 阻塞。

但是，這都是有工作量且阻塞時間不可控的。而這個命令直接解決了我這個問題，至少讓我少走了幾步彎路吧。

同樣，這個 issues 里面還關聯了幾個其他的 issues ，這些都是官方認為是同一個原因造成的問題：

然后怎么解決的呢？

常規來說，他們應該關聯一個 pr，通過這個 pr 我就能直接關聯到對應的修復的內容。

但是這次他們搞了一個騷操作，直接先弄了一個 SNAPSHOT 版本，并沒有關聯 pr：

怎么辦？

這個時候我想去看他是怎么修復這個問題的，怎么辦？

前面提到的 idea 里面的 git 插件就派上用場了。

首先，從他的評論時間我知道是 2019 年 3 月 13 號，那么我可以直接在工具里面定位到那一天提交的內容。

點擊 Version Control 視圖里面的 Log 標簽，就可以看到整個項目歷史上的所有的提交，它會按照時間的順序給你排好序，所以很容易就找到了當天的相關的提交：

你要是覺得難得找，也可以直接通過日期進行過濾：

從當天提交的這個 commit 信息來看，就知道我找對地方了。

而這里就只是修改了 RedissonLock.java 這個類，所以我就找到了這個關鍵的類：

然后點進去再分析一下這個類具體的修改，這樣算是找到了 debug 的時候我應該重點關注的地方。

又比如看門狗失效的那個 bug：

https://github.com/redisson/redisson/issues/3714

在這里面，就是直接關聯了一個 pr，然后我們可以通過這個鏈接，找到提交的代碼，也可以找到其對應的 issues。

這玩意屬于雙向奔赴了。

而且我也能知道這次提交對應的類叫做 RedissonBaseLock.java：

那我又可以回到 idea 的視圖里面，直接看看這個類的提交記錄了：

一看才發現，這個哥們一共提交了三次。而且還發現這個類還挺年輕的， 2021 年 1 月 21 日才首次提交。

我之前在?《踩到一個關于分布式鎖的非比尋常的BUG！》?這篇文章里面留了個思考題：

就是由這三次提交引起的。

我帶你看一下這三次提交分別是什么。

首先第一次提交，加入了 else 分支，里面執行了一次 cancelExpirationRenewal 方法，入參是 threadId。

含有是把當前線程的重入次數減一。

但是能走到 else 分支里面來有個大前提是給鎖續命的 lua 腳本返回 false，也就是說這個鎖都沒了。

鎖都沒了，還維護重入次數干啥呢？

直接從 MAP 里面把這個對象拿掉就行了。

怎么拿掉呢？

傳入 null 就可以了：

所以，才有了第二次提交，把入參從 threadId 修改為 null：

那么第三次提交又是干啥呢？

是不是完全看不出來是干啥？

別急，我這樣給你上個截圖你就懂了：

之前是用的 tab 制表符，后來修改為四個空格。這是編碼風格的問題。

提到用 tab 還是用空格，這又是另外一個在編程領域里面爭論不止的話題了。

我記得之前我看過一個美劇，叫做《硅谷》。里面的主人公就因為到底應該用 tab 還是用空格和女朋友吵了一架。

然后...

我寫文章的時候還想起了一個無聊的問題，并且去尋找到了答案。

我想知道 Redisson 是在什么時候引進看門狗機制的，我想看看這個狗子最開始的模樣。

我怎么找的呢？

首先我知道啟動看門狗的代碼是位于 RedissonLock.java 中的 renewExpiration 這個方法：

那我就在 RedissonLock.java 的歷史提交記錄里面用找一下 renewExpiration 這個方法什么時候是第一次提交的就行了。

于是我很快就找到了 2019 年 3 月 13 日的這次：

我才發現原來看門狗還換過名字，它之前叫做 scheduleExpirationRenewal，后來才改名叫 renewExpiration。

很顯然，我覺得新名字更好。

然后我就繼續找 scheduleExpirationRenewal 是什么時候第一次出現的，我找啊找啊，找到了 2015 年 12 月 14 日的這次提交：

好家伙，這個狗子還有個叫做 newRefreshTask 的曾用名啊。

最終，找到了 newRefreshTask 第一次出現的地方，就是 2015 年 7 月 4 日：

這就是看門狗的生日，距離今天不到兩個月了，我提前祝它生日快樂。

但是，我不得不吐槽一句：?這一次提交，除了?看?門狗之外，?其實還提交了非常多的東西。

可以在這次提交上右鍵，然后點擊下面框起來的選項：

就能看到這次提交的所有東西：

提交了 31 個文件，其中包含了看門狗機制。

但是提交的 commit 信息非常簡陋，只體現了因為涉及到事務操作，所以使用了 LUA 腳本的這一個特性。

這就是一個非常不好的 commit 提交示例。

但是你轉念一想，你每次提交的時候示例是怎么寫的，是不是也經常偷懶。

別問我是怎么知道。

所以，每次提交的 commit 信息還是要認真寫的，因為你要知道，總是有我這樣無聊的人，會去翻一些沒啥卵用的知識點出來。

比如我問你，我找看門狗機制的這段描述，除了讓你知道它的生日和幾個曾用名之外還有什么卵用嗎？

是的，沒有。

恭喜你又學到了一個沒啥卵用的知識點。

再來一個

我再帶你看一個項目，Dubbo。

還是按照我前面說的，把項目拉下來，然后點擊這里的 log，就可以看到整個項目歷史上的所有提交：

拉到最下面，可以找到歷史上第一次提交的情況：

第一次提交是梁飛在 2011 年 10 月 20 日 23 點 04 分提交的。

但是從提交的 commit 信息來看，我們也知道這是一次空提交。

真正的第一次提交是 2 分鐘之后的 23 點 06 分：

9 個模塊，共計 669 個文件，就是日后這個一路坎坎坷坷、幾近夭折、友商續命，最終成為 Apache 頂級開源項目的雛形。

11 年前的 10 月 20 日，梁飛從晚上 23 點干到了凌晨 5 點 25 分，終于給 Dubbo 打上了第一個里程碑 tag：2.0.7。

期間，還發布了一個微博：

而他自己，第二天的中午，也在自己的博客上公布了這件事情：

https://www.iteye.com/blog/javatar-1206888

為什么 Dubbo 會選在這一天進行開源呢？

我想應該是為了趕上兩天之后的 Qcon ?全球軟件開發者大會：

那一天，才是 Dubbo 真正意義上，站在大眾視野里，接受贊揚與嘲諷的開始。

在 idea 的視圖里面，還可以過濾指定的人提交的記錄。

比如梁飛就用過下面這幾個賬號提交代碼：

我過濾了一下，發現多達 1294 次，最后一次提交在 2015 年 4 月 1 日：

而且我還發現他特別能肝，類似這樣時間點的提交記錄有好幾處：

然后我還找了幾個類，想看看經過 10 多年的發展，這些類中還留下多少他的代碼。

首先我給你看看這個負載均衡策略相關的類 AbstractLoadBalance.java。

在這個類上右鍵，然后選擇 git->Annotate 就可以調出左邊的(時間-用戶)的視圖：

這就表示的是當前這個類，每一行代碼是誰在什么時候提交的。

還是可以看到梁飛的身影。

而且我給你看看這個：

這個方法是 Dubbo 啟動的時候，給新機器預熱，一點點的給權重。第一分鐘給 10% 的流量，第二分鐘給 20% 的流量...第十分鐘這個時候機器基本上已經經過充分的預熱，所以可以給到 100% 的流量。

至于為什么要預熱呢，這個就和 JVM 相關了，你如果感興趣的話，可以去研究一下。

就是這個功能，這一個核心方法，經過 10 多年時間，除了一點微調，其核心算法、核心邏輯沒有發生一點變化。

再比如，我給你看看最少活躍數負載均衡策略的實現 LeastActiveLoadBalance.java：

從初始化提交之后，一共就沒修改過幾次。

但是你要知道每次提交都是有它的意義的，比如這兩次：

一次提交是把變量 leastIndexs 修改為 leastIndexes，因為 index 是 x 結尾的，以 s、x、sh、ch 結尾的名詞，它的復數形式應該是加 es。這是一個英語小知識。

一次提交是把 Random 替換為 ThreadLocalRandom，因為后者性能更好，這是編程小知識，背后的原因是值得深挖的。就看有沒有有心人了。

你也可以對比一下，初始版本和當前最新的版本，核心算法、核心邏輯基本沒有發生變化：

這兩個類告訴我一個什么道理？

比起業務代碼的增刪改查，只有算法，穩定的算法才是更容易在歲月的長河中留下來的，而且歷久彌新。

然后，再回到 log 的標簽中，你會發現一個很奇怪的現象。

整個 2014 年到 2015 年，都沒有提交過幾次代碼：

其實從 2013 年開始到 2017 年基本上就沒多少提交了。

這是為什么呢？

這就不得不說一下 Dubbo 坎坷的一生了。

前面說了，2011 年它是屬于出生豪門，從阿里開源走了出來。

但是在 2012 年 10 月 23 日，Dubbo 2.5.3 發布后，阿里就基本上停止了對于 Dubbo 的維護升級。

然后一直到 2017 年 9 月 7 日，Dubbo 悄悄在 GitHub 發布了 2.5.4 版本。隨后，又迅速發布了 2.5.5、2.5.6、2.5.7 等版本。在 10 月舉行的云棲大會上，阿里宣布 Dubbo 被列入集團重點維護開源項目，這也就意味著 Dubbo 起死回生，開始重新進入快車道。

在 2012 年到 2017 年這五年間，當當網自己拉了一個 Dubbox 的分支開搞，相當于幫 Dubbo 把命給續住了。

2018 年 1 月 8 日，Dubbo 2.6.0 版本發布，新版本將之前當當網開源的 Dubbox 進行了合并，實現了 Dubbo 版本的統一整合。

然后 2018 年 2 月，阿里巴巴宣布將 Dubbo 捐獻給 apache，進入 apache 孵化器。

2019 年 5 月 21 號，經過了漫長的孵化期，Dubbo 迎來了畢業。成為Apache基金會頂級項目。

之后的故事你應該也就知道了，Dubbo 現在都搞到 3.0 了，準備在云原生的賽道上發力。

所以你看，這妥妥的就是一個爽文的套路啊。

這就是一個富家子弟不慎流落街頭，被人收養，悉心照料，最后在一片驚呼中，又重回巔峰的故事啊。

那么這個故事告訴了我們一個什么道理呢？

它告訴我們，有個好爸爸真的是太好了。要是 Dubbo 不是阿里開源出來的，起死回生是很難了，對半已經是消失在歷史的長河中了。

話說回來，前面提到的這些東西，都是可以由我這篇文章給你提到的這個 idea 的視圖衍生出來的。

而且我只是給你介紹了一些非常常規的用法，你可以自己去挖掘出更適合你自己的關注點。

這玩意，平時自己沒事，拉個自己感興趣的項目下來，看看提交記錄，看看新特性。

就像我前面說的，每次提交都是有它的意義的，有的提交背后是值得深挖的，就看有沒有有心人了。

你說，這玩意難道不比小說好看嗎？

好了，那本文的技術部分就到這里啦。

下面這個環節叫做[荒腔走板]，技術文章后面我偶爾會記錄、分享點生活相關的事情，和技術毫無關系。我知道看起來很突兀，但是我喜歡，因為這是一個普通博主的生活氣息。

你要不喜歡，退出之前記得文末點個“在看”哦。

荒腔走板

昨天寫了這篇文章?《之后，我再也沒有去過北京?！?/p>

想寫這篇文章的契機是因為前幾天官宣即將在成都舉辦的第 31 屆大運會又延期了。

大運會，和北京馬拉松一樣，本來也應該是一個一期一會的事情，但是這已經是它第二次延期了。

所以一期一會是一個美好的詞，但是也是一個非常難做到的詞。不可抗力，就是不可抗力，它并不以個人意志為轉移。

成都大運會，這是繼 2001 年北京大運會、2011 年深圳大運會之后，中國大陸第三次舉辦世界大學生夏季運動會，也是中國西部地區第一次舉辦世界性綜合運動會，對于中國西部，對于成都的重要意義，不言而喻。

看延期的消息的時候，我也只能驚呼一聲：哦豁。

第一次延期到 2022 年 6 月 26 日開幕。第二次，也就是這次，大概率是延期到 2023 年了。

如果要往前追溯成都和大運會最開始的交集，可以追溯到 2019 年初。

在這期間，這么多志愿者、工作人員、政府部門都付出了巨大的精力和努力。

還有一個特殊的群體：大學生，特別是成都大學的大學生，又特別是 2019 屆之后成都大學的大學生。因為大運村項目選址在成都大學。

2019 年到 2023 年，剛好四年。

大一到大四，也剛好四年。

成都大學的同學們為了大運會的順利舉辦，課程安排各種調整，周末和節假日也要補課。學生宿舍也是搬來搬去。

結果到現在臨門一腳了，哦豁，延期了。

這真是一件所有人都不愿意看到的，但是又不得不接受的令人悲傷的事情。

成都，需要這樣的一次國際性賽事來擦亮自己的名牌。但是成都更需要的是安全。

待到春暖花開的季節，山河無恙，歲月安康之后，“再次迎大運”吧。

總結

以上是生活随笔為你收集整理的算是我看源码时的一个小技巧吧~的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。