以前好好的現在壞了：git bisect 二分定位迴歸 Bug 提示詞（附自動判定腳本）
某個功能在舊版本正常、新版本壞了，但中間隔了幾十上百個提交不知道是哪個引起的時候用：讓 AI 幫你寫好 git bisect 的完整步驟和「好 / 壞」自動判定腳本，幾輪就能定位到出問題的那次提交。
通用大模型 對話模型通用
請幫我用 git bisect 找出引入問題的那次提交。 資訊： - 問題現象：[壞的表現] - 確定正常的版本：[標籤或提交號] - 確定有問題的版本：[通常是當前分支] - 怎麼判斷好壞：[手動操作步驟或測試命令] - 項目的構建 / 依賴安裝方式：[如 npm ci、mvn package] - 操作系統與 shell：[操作系統與 shell]（例：macOS zsh、Windows Git Bash） 請給出： 1. 完整命令序列：從開始、標記好壞、每輪測試，到結束後回到原分支。說明每條命令的作用。 2. 一個可以交給 git bisect run 的判定腳本，要求： - 每輪先安裝依賴、構建（只做必要的步驟，盡量快）； - 問題存在時以 1 到 127 之間、不是 125 的碼退出，正常時以 0 退出； - 遇到構建失敗等「這一版本沒法判斷」的情況，以 125 退出讓 bisect 跳過； - 不修改倉庫裏被跟蹤的文件，臨時文件放到倉庫外。 3. 如果判斷方式只能手動，給出每一輪我該做什麼、怎麼標記的簡短清單。 4. 預估大概需要幾輪（按提交數量計算）。 5. 找到可疑提交後，下一步怎麼做：看這次提交改了什麼、怎麼確認它就是原因（比如在當前版本上單獨回退這次提交再測）、修復時要注意什麼。 注意事項也要寫：開始前要確保工作區乾淨；中間有合併提交時怎麼處理；判定命令依賴的測試文件在舊版本里不存在時怎麼辦。
高亮處換成你自己的內容：[壞的表現]、[標籤或提交號]、[通常是當前分支]、[手動操作步驟或測試命令]、[如 npm ci、mvn package]、[操作系統與 shell]
ChatGPT Plus 充值
已被複製 0 次
使用說明
怎麼填變量：[怎麼判斷好壞] 寫得越機械越好，最好是一條命令，比如「運行 npm test -- price.test.ts，失敗就是壞」。能自動判定時，bisect 可以全自動跑完，你去喝杯咖啡就行。
常見坑：
- 判定用的測試文件如果是最近才加的，舊版本里沒有它。解決辦法是先把測試文件複製到倉庫外，判定腳本每輪從外面拷進來再運行。
- 舊版本的依賴可能裝不上或構建失敗，這種版本應該「跳過」而不是標成壞，否則會定位錯。
- 結束後一定要
git bisect reset，否則倉庫停在某個舊提交上。
追問技巧：定位到提交後，把這次提交的 diff 貼回去，問「這次改動裏哪一處最可能導致 [壞的表現]，給出最小修復」。
示例輸出
示例，僅供參考（正常版本 v2.3.0，當前 main 有問題，約 120 個提交）
bash
git status # 確認工作區乾淨
git bisect start
git bisect bad # 當前版本有問題
git bisect good v2.3.0 # 這個版本正常
cp tests/price.test.ts /tmp/ # 測試文件放到倉庫外
git bisect run /tmp/check.sh # 自動二分
git bisect reset # 回到原分支bash
#!/usr/bin/env bash
# /tmp/check.sh
npm ci --silent || exit 125 # 裝不上依賴：跳過這一版
cp /tmp/price.test.ts tests/price.test.ts
npx vitest run tests/price.test.ts; code=$?
git checkout -- tests/ 2>/dev/null; git clean -fdq tests/
[ $code -eq 0 ] && exit 0 || exit 1約 120 個提交，二分大約需要 7 輪。
同款作品
用這條提示詞做出來的作品；原作者會因此獲得積分
還沒有同款，來做第一個。
0 條評論
還沒有評論，來搶沙發～