慣性聚合 高效追蹤和閱讀你感興趣的部落格、新聞、科技資訊
閱讀原文 在慣性聚合中打開

推薦訂閱源

博客园 - 司徒正美
V
V2EX
T
Tailwind CSS Blog
有赞技术团队
有赞技术团队
aimingoo的专栏
aimingoo的专栏
Apple Machine Learning Research
Apple Machine Learning Research
IT之家
IT之家
Blog — PlanetScale
Blog — PlanetScale
A
About on SuperTechFans
月光博客
月光博客
T
The Blog of Author Tim Ferriss
宝玉的分享
宝玉的分享
Martin Fowler
Martin Fowler
博客园 - 聂微东
The GitHub Blog
The GitHub Blog
V
Visual Studio Blog
WordPress大学
WordPress大学
酷 壳 – CoolShell
酷 壳 – CoolShell
Engineering at Meta
Engineering at Meta
GbyAI
GbyAI

阮一峰的网络日志

科技爱好者周刊(第 396 期):互联网通信的替代方案 科技爱好者周刊(第 396 期):互联网通信的替代方案 - 阮一峰的网络日志 科技爱好者周刊(第 395 期):软件开发的第三种方式 科技爱好者周刊(第 395 期):软件开发的第三种方式 - 阮一峰的网络日志 科技爱好者周刊(第 393 期):脑腐状态 科技爱好者周刊(第 392 期):axios 投毒与好莱坞式骗术 科技爱好者周刊(第 391 期):AI 的贫富分化 科技爱好者周刊(第 390 期):没有语料,大模型就是智障 套壳中国大模型撑起500亿美元估值?扒一扒 Cursor 的"套壳"疑云 科技爱好者周刊(第 389 期):未来如何招聘程序员 科技爱好者周刊(第 388 期):测试是新的护城河 零安装的"云养虾":ArkClaw 使用指南 科技爱好者周刊(第 387 期):你是领先的 科技爱好者周刊(第 386 期):当外卖员接入 AI 字节全家桶 Seed 2.0 + TRAE 玩转 Skill 科技爱好者周刊(第 385 期):马斯克害怕中国车企吗? 智谱旗舰 GLM-5 实测:对比 Opus 4.6 和 GPT-5.3-Codex 科技爱好者周刊(第 384 期):为什么软件股下跌 科技爱好者周刊(第 383 期):你是第几级 AI 编程 Kimi 的一体化,Manus 的分层 科技爱好者周刊(第 382 期):独立软件的黄昏 AI native Workspace 也许是智能体的下一阶段 科技爱好者周刊(第 381 期):中国 AI 大模型领导者在想什么 科技爱好者周刊(第 380 期):为什么人们拥抱"不对称收益" 科技爱好者周刊(第 379 期):《硅谷钢铁侠》摘录 我如何用 AI 处理历史遗留代码:MiniMax M2.1 升级体验 科技爱好者周刊(第 378 期):预测是新的互联网热点 科技爱好者周刊(第 377 期):14万美元的贫困线 科技爱好者周刊(第 376 期):太空数据中心的争议 科技爱好者周刊(第 375 期):一扇门的 Bug 终于有人做了 Subagent,TRAE 国内版 SOLO 模式来了 科技爱好者周刊(第 374 期):6GHz 的问题 VS Code 使用国产大模型 MiniMax M2 教程 科技爱好者周刊(第 373 期):数据模型是新产品的核心 国产大模型接入 Claude Code 教程:以 Doubao-Seed-Code 为例 科技爱好者周刊(第 372 期):软件界面如何设计 大模型比拼:MiniMax M2 vs GLM 4.6 vs Claude Sonnet 4.5 科技爱好者周刊(第 371 期):一个乐观主义者的专访 科技爱好者周刊(第 370 期):正确的代码高亮 错误处理:异常好于状态码 科技爱好者周刊(第 369 期):Tim 与罗永浩的对谈 科技爱好者周刊(第 368 期):不要这样管理软件团队 一天之内,智谱和 Anthropic 都发了最强编程模型 科技爱好者周刊(第 367 期):Nano Banana 的几个妙用 科技爱好者周刊(第 366 期):旧金山疯狂的 AI 广告 科技爱好者周刊(第 365 期):流量变现正在崩塌 科技爱好者周刊(第 364 期):最难还原的魔方 科技爱好者周刊(第 363 期):最好懂的神经网络解释 科技爱好者周刊(第 362 期):GitHub 工程师谈系统设计 科技爱好者周刊(第 361 期):暗网 Tor 安全吗?
git bisect 命令教程
阮一峰 · 2018-12-24 · via 阮一峰的网络日志

git bisect是一個很有用的命令,用來查找哪一次代碼提交引入了錯誤。

它的原理很簡單,就是將代碼提交的歷史,按照兩分法不斷縮小定位。所謂"兩分法",就是將代碼歷史一分為二,確定問題出在前半部分,還是後半部分,不斷執行這個過程,直到範圍縮小到某一次代碼提交。

本文通過一個實例,解釋如何使用這個命令。下面是一個代碼庫,請將它克隆到本地。


$ git clone [email protected]:bradleyboy/bisectercise.git
$ cd bisectercise

這個庫是一個網頁index.html,在瀏覽器打開這個網頁。


$ open index.html

網頁上是一個計數器,有兩個按鈕。點擊+號按鈕,可以看到計數器沒有遞增,反而遞減,這說明代碼有問題。

現在,就要來查找,到底哪一次代碼提交,引入了錯誤。首先,檢查一下代碼提交歷史。


$ git log --pretty=oneline

可以看到,這個庫一共有101次提交。最早的第一次提交的哈希是4d83cf

git bisect start命令啟動查錯,它的格式如下。


$ git bisect start [終點] [起點]

上面代碼中,"終點"是最近的提交,"起點"是更久以前的提交。它們之間的這段歷史,就是差錯的範圍。

這個例子中,我們選擇全部的代碼歷史。起點是第一次提交4d83cf,終點是最近一次的HEAD。當然,指定其他範圍也可以。


$ git bisect start HEAD 4d83cf

執行上面的命令以後,代碼庫就會切換到這段範圍正當中的那一次提交,本例是第51次提交。

現在刷新瀏覽器,點擊+按鈕,發現可以正常遞增。使用git bisect good命令,標識本次提交(第51次)沒有問題。


$ git bisect good

既然第51次提交沒有問題,就意味著錯誤是在代碼歷史的後半段引入的。執行上面的命令,Git 就自動切換到後半段的中點(第76次提交)。

現在刷新瀏覽器,點擊+按鈕,發現不能正常遞增。使用git bisect bad命令,標識本次提交(第76)有問題。


$ git bisect bad

執行上面的命令以後,Git 就自動切換到第51次到第76次的中點(第63次提交)。

接下來,不斷重複這個過程,直到成功找到出問題的那一次提交為止。這時,Git 會給出如下的提示。


b47892 is the first bad commit

既然找到那個有問題的提交,就可以檢查代碼,確定具體是什麼錯誤。

然後,使用git bisect reset命令,退出查錯,回到最近一次的代碼提交。


$ git bisect reset

現在就可以開始修復錯誤了。

(完)