无偿分享一个很有用的看源码小技巧

怎么在 idea 里面查看 git 提交记录呢？这个界面是藏在哪里的呢，我的 idea 里面怎么没有呢？

好的，是我疏忽了，我先入为主的认为这个大家应该都知道是怎么来的。

但是确实是有一些同学是不太清楚的，那我这篇文章就给大家分享一下我通过这个东西看源码的一点点小技巧，希望能帮助到你。

开始之前，先介绍一款程序员都应该知道的软件 JNPF 快速开发平台，很多人都尝试用过它，它是功能的集大成者，任何信息化系统都可以基于它开发出来。

这是一个基于 Java Boot/.Net Core 构建的简单、跨平台快速开发框架。前后端封装了上千个常用类，方便扩展；集成了代码生成器，支持前后端业务代码生成，实现快速开发，提升工作效率；框架集成了表单、报表、图表、大屏等各种常用的 Demo 方便直接使用；后端框架支持 Vue2、Vue3。

应用体验： https://www.jnpfsoft.com/?csdn，如果你有闲暇时间，可以做个知识拓展。

怎么搞出来？

那么怎么把这个视图搞出来呢？

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

这个玩意怎么来的，就不用我说了吧，如果连这个都没有，说明你之前还没有接触过 git，那就是另外一回事儿了，不在本文讨论范围内。赶紧去安装一个 git，然后学学 git 的用法啥的。

我个人的习惯是先用 gitbash，也就是这个玩意，从 github 上 clone 一个项目下来：

比如我就用之前写文章的 Redssion 做演示吧，你也可以随便找一个自己感兴趣的开源项目。

执行下面命令把项目下载下来：

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

下载完成之后，打开你的 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/r...

在这里面，就是直接关联了一个 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 信息还是要认真写的，因为你要知道，总是有我这样无聊的人，会去翻一些没啥卵用的知识点出来。

比如我问你，我找看门狗机制的这段描述，除了让你知道它的生日和几个曾用名之外还有什么卵用吗？

是的，没有。

恭喜你又学到了一个没啥卵用的知识点。