git bisect 在多分支下易失效，因其默认基于线性历史，而合并提交使提交图变为dag，导致跳入无关分支、漏掉关键变更或误判merge commit；需限定路径、校验可达性、谨慎处理merge及自动化脚本容错。
Git Bisect 为什么在多分支下容易失效
因为 git bisect 默认只基于单条线性历史工作，而多分支合并（尤其是 merge commit）会让提交图谱变成 DAG，git bisect 可能跳进无相关代码的分支、漏掉关键变更，甚至把 merge commit 误判为“好”或“坏”——它不理解你关心的是哪条路径上的改动。
常见现象：运行 git bisect start 后，git bisect good / git bisect bad 指定的提交不在同一演化路径上；或者 bisect 过程中检出的某个中间提交根本没包含你要定位的 feature 文件。
- 确保
bad提交必须能复现 Bug，且它确实继承自你怀疑的变更路径（比如来自feature/login-flow分支的 merge） -
good提交不能随便选 master 上一个旧版本——得是该 feature 开发前、且不含任何相关逻辑的提交，最好直接用该 feature 分支的起始 commit（如git merge-base feature/login-flow main的结果） - 如果
bad是 merge commit，先用git show --oneline -m <merge-commit></merge-commit>看它引入了哪些 parent，再决定是否要git bisect skip那些无关 parent 的提交
如何限定 bisect 范围到特定分支路径
核心是让 git bisect 只考虑从 good 到 bad 的可达路径，而不是整个 DAG。最可靠的方式是显式构造一条“可追溯子集”：
- 用
git rev-list --ancestry-path <good>..<bad></bad></good>列出所有严格位于good → bad路径上的提交（排除旁支 merge 引入的无关 commit） - 把结果保存为临时文件：
git rev-list --ancestry-path good-commit^..bad-commit > bisect-candidates.txt - 启动 bisect 时加
--no-checkout，再用git bisect replay或手动git checkout配合该列表做二分——但更实用的是：直接用这个列表过滤git bisect的候选集 - 实际操作中，可先
git bisect start bad-commit good-commit，然后对每次 bisect 检出的 commit，运行git merge-base --is-ancestor good-commit HEAD && git merge-base --is-ancestor HEAD bad-commit双重校验，不满足就git bisect skip
遇到 merge commit 怎么安全跳过或拆解
merge commit 本身不带变更，真正的问题藏在它的 first-parent（通常是主干）或 second-parent（被合并分支）里。bisect 默认走 first-parent，但 Bug 往往来自 second-parent 的新逻辑。
- 当
git bisect停在 merge commit 时，先执行git show --stat <merge-commit></merge-commit>，确认变更是否来自 merged 分支 - 若变更确实在 second-parent，运行
git bisect skip，然后手动检出 second-parent：git checkout <merge-commit>^2</merge-commit>，测试并标记git bisect bad或git bisect good - 更稳妥的做法：在 start 前，用
git log --first-parent <bad></bad>和git log <bad>^2</bad>分别看主干和被合并分支的历史，优先在后者上做 bisect - 注意：不要对 merge commit 直接
git bisect bad，除非你能 100% 确认 Bug 就由这次 merge 引入（比如 CI 失败点就是 merge commit）
自动化验证脚本必须处理非 clean 状态
多分支环境下，bisect 过程中检出的提交可能缺少依赖分支的 patch，或存在未解决的 merge conflict，导致 npm install 失败、编译报错，进而误判为 “bad”。验证脚本不能假设每次检出都是可构建的。
- 脚本开头加
git status --porcelain | grep -q "." && exit 125：若工作区脏，返回 125 让 bisect 自动 skip - 构建前先
git reset --hard && git clean -fdx，避免残留文件干扰 - 若项目依赖其他分支的未合入代码，验证脚本应提前
git merge origin/dep-feature --no-commit --no-ff 2>/dev/null || true（仅用于测试，不提交） - 测试命令建议用
set -e+ 显式 exit code 判断，比如npm test && node ./repro-bug.js || exit 1，让 bisect 准确识别失败
真正难的不是跑通 git bisect，而是判断哪个提交“算数”——它得同时满足：在目标功能路径上、能干净构建、且复现逻辑一致。人工介入往往比参数调优更重要。
