共计 1612 个字符,预计需要花费 5 分钟才能阅读完成。
导读 | Git 的 bisect 工具通过快速识别坏的提交,节省了时间和精力。 |
你是不是有过这样的经历:发现代码中有 错误 bug,但不知道这个错误是什么时候引入的。这有可能是因为,某个人提交了一份有错误的代码,但没有在他的 Git 提交 commit 消息中声明它。这个错误可能已经存在了几周、几个月甚至几年,这意味着你需要搜索数百或数千个提交,才能找到问题何时出现的。而 git bisect 命令能够完美地解决这个问题!
git bisect 命令是一个强大的工具。你可以给 git bisect 命令一个范围,一端是一个已知的好状态,另一端是一个已知的坏状态。它会自动地确认当前范围的中点,在这个中点上进行测试,然后要求你确定那次提交是一个 好提交 good commit 还是一个 坏提交 bad commit,然后它会重复这一“二分查找”的过程,直到你找到首次引入错误的那一次提交。
这个“数学”工具是利用“二分查找”来找到错误之处的。git bisect 命令通过查看中点,然后由你来决定它是提交列表的新起点(即“坏提交”)还是新终点(即“好提交”),进而来缩小查找范围,如此在几次查找中你可以就能定位到有错误的提交。即使你有 10,000 个提交要检查,最多只需要 13 次查找,就能很快地定位到首次引入错误的提交。
- 提交 1 坏 提交 10,000 好 => 提交 5,000 是坏的
- 提交 5,000 坏 提交 10,000 好 => 提交 7,500 是好的
- 提交 5,000 坏 提交 7,500 好 => 提交 6,250 是好的
- 提交 5,000 坏 提交 6,250 好 => 提交 5,625 是坏的
- 提交 5,625 坏 提交 6,250 好 => 提交 5,938 是坏的
- 提交 5,938 坏 提交 6,250 好 => 提交 6,094 是好的
- 提交 5,938 坏 提交 6,094 好 => 提交 6,016 是坏的
- 提交 6,016 坏 提交 6,094 好 => 提交 6,055 是好的
- 提交 6,016 坏 提交 6,055 好 => 提交 6,036 是坏的
- 提交 6,036 坏 提交 6,055 好 => 提交 6,046 是坏的
- 提交 6,046 坏 提交 6,055 好 => 提交 6,050 是坏的
- 提交 6,050 坏 提交 6,055 好 => 提交 6,053 是好的
- 提交 6,053 坏 提交 6,055 好 => 提交 6,054 是好的
对于上面这个例子,我们能知道 10,000 个提交中的第一个错误提交是第 6053 次提交。对于 git bisect 命令,最多需要几分钟就能完成检索。但是如果要一个一个查找每个提交是否错误,我甚至无法想象需要多长时间。
git bisect 命令使用起来非常简单:
(LCTT 译注:使用 git bisect start 命令来进入 bisect 模式,并且该命令指定了一个检查范围。它会告诉我们一共有多少次提交,大概需要几步就可以定位到具体的提交。)
$ git bisect start$ git bisect bad # Git assumes you mean HEAD by default$ git bisect good # specify a tag or commit ID for
Git 检查中间的提交,并等待你声明这次提交是一个好提交还是一个坏提交:
(LCTT 译注:如果某一提交是可以通过的,则使用 git bisect good 命令标记;同样地,如果某一提交不能通过,则使用 git bisect bad 命令标记。)
$ git bisect good
或
$ git bisect bad
然后,git bisect 工具重复检查好提交和坏提交中间的那次提交,直到你告诉它:
$ git bisect reset
一些高级用户甚至可以自己编写脚本,来确定提交的好坏状态、并在找到特定提交时采取某一补救措施。你可能不会每天都使用 git bisect 命令,但当你需要它来定位首次引入错误的提交时,它会是一个很有用的救星。
![post-qrcode](https://www.xgss.net/wp-content/uploads/2023/07/二维码-微信公众号256x256.jpg)