用 Git 二分缩小变化范围时，先让好坏判定稳定

先确定你要寻找哪一种变化

假设本地项目以前能够处理某个有限输入，现在结果不同。提交历史很多，维护者希望用 Git 二分快速定位。开始以前，先把变化写成一个具体判定：同一输入在给定条件下是否得到约定结果。不能一边搜索“结果不正确”，一边在每个版本采用不同输入或不同解释。二分需要可重复回答的问题，工具本身不会替项目决定哪些行为属于缺陷。

Git 官方手册说明，bisect 根据已知的两端与中间版本的判断缩小范围，也可用于寻找一般属性变化，不只限于错误。这个能力建立在维护者提供有效判定的前提上。若好坏标签来自印象或不稳定测试，搜索再高效也可能收窄到错误方向。准备工作不是额外负担，而是让每次判断真正支持下一步。先让问题稳定，才值得让工具减少历史检查量。

两个端点都要在同一政策下核对

不能仅凭记忆说某个旧版本一直正常。应在能够控制的本地条件下，用相同测试核对选定端点，保存输入、预期与实际结果。旧版本可能依赖不同构建前提，当前环境也可能已经变化。若端点没有真正满足判定，后续搜索的基本假设就不成立。确认范围比直接开始遍历更有效，也能帮助发现问题其实来自环境而非提交内容。

端点不必只叫好与坏，但名称应表达当前属性，不在搜索过程中随意换义。若目标是寻找某种格式政策改变，就应始终按该政策分类，而不是把“构建成功”与“功能正确”交替当成同一个标签。一个版本能够构建，但目标行为不符；另一个版本暂时无法构建，不能因此自动归为相同业务状态。不同层次的结果应当保持区别，避免让搜索吸收错误信息。

把判定写成独立且有限的测试

测试最好能够从当前选中的源码建立目标产物，再运行最小输入，检查与属性相关的结果。不能每次切换源码后仍启动同一份旧二进制，否则看起来一直稳定，实际根本没有比较版本。构建与运行入口应明确，历史残留不应决定结果。有限测试目录和清楚产物身份，可以减少这种常见混淆，也便于后来复查每次标签的依据。

测试本身应尽量位于不会被历史切换悄悄改变的位置，或有明确的版本政策。若判定脚本随被测版本一起变化，就可能在不同提交中采用不同规则，失去可比性。具体保存方式由项目决定，但需要在记录中说明。独立判断不等于必须引入复杂框架，往往一个简短、可读且有已知预期的脚本就足够，关键是它始终回答同一个问题。

无法测试不应该被强行标成不符合

历史版本可能因为当前环境缺少依赖而暂时无法构建，也可能在目标功能尚不存在时没有可比接口。此时应区分无法判断与真正违反预期。Git 提供跳过无法测试版本的机制，但使用以前需要有明确原因。不能为了让搜索继续推进，就把所有构建障碍都归为业务失败，这会让工具搜索的是环境兼容变化，而非原来准备研究的行为。

跳过也不是没有代价。若关键附近存在多个无法判断的版本，最终可能无法唯一确定候选。报告应保留这种范围，而不是随意挑其中一个当作根因。可以继续设法在受控条件下补充证据，或说明当前材料只支持一个候选集合。诚实表达不确定性，比给出看起来精确却没有依据的提交编号更有价值，也更便于安排下一步调查。

自动化判定需要理解退出结果约定

Git 手册描述了自动运行判定的功能及相应结果约定。接入时应查阅实际版本说明，确认测试脚本怎样表达两类判断与无法完成，而不是把所有非零结果不加区别地交给工具。脚本中的构建失败、测试前提缺失和行为不符，可能需要不同处理。只有转换关系明确，自动化才会放大正确判断，而不是更快传播错误标签。

在大范围自动搜索以前，可以先手工运行判定脚本，验证它在已知端点上得到预期结果。再检查它是否真正使用当前产物、是否保留必要诊断、是否会受到旧文件影响。自动化不应省略这些前提。若脚本会执行外部任务或修改资料，应将其限定在自有本地范围，保持可恢复且有限，不让一次历史调查变成无意触发的实际业务操作。

稳定性不足时先暂停标签传播

如果同一版本在相同条件下有时符合、有时不符，不能根据任意一次结果就给它永久标签。应先调查不稳定来源，或者为判定建立能够说明局限的政策。输入随机性、时序、外部前提或资源条件都可能影响观察。重复运行可以帮助描述稳定性，但不能仅挑选符合期待的一次。搜索过程需要可信比较，而不是将不确定性隐藏在一个看似确定的标签中。

若暂时无法使问题稳定，可以先保留失败样本与条件，再选择其他调查方法。二分是缩小历史范围的工具，不是每个问题都必须使用的流程。不能为了继续操作而改变目标，让原本的问题逐渐变成另一种更容易判断的属性。选择方法应服务于证据，方法遇到前提不足时应明确限制，而不是让工具界面推动结论超过实际观察。

保持构建条件可以比较

不同历史版本可能需要不同配置，但如果每次随意调整，就难以知道结果变化来自提交还是环境。应尽量保持与研究问题相关的条件一致；确需变化时，记录它为什么必要，以及如何影响解释。对于版本间不兼容的构建前提，可以先建立受控方案，而不是在每一步临时猜测。清楚的条件让标签有依据，也能减少搜索结束后无法重放的情况。

还要避免对象与缓存跨版本混用。切换源码并不自动证明全部产物都与之对应，尤其当构建依赖不完整时。可以采用项目支持的受控构建方式，确认目标来自当前材料。这里不要求无差别删除所有目录，更不能触及无关资料。构建策略应当有限、明确且能保留调查证据，让每一步比较都有真实版本身份，而不是比较同一个残留程序。

保存判定过程，便于发现错误标签

搜索中记录每次版本、测试条件与结果，可以在后来发现一次误判时重新核对。Git 也提供记录与重放相关机制，适合按文档管理过程。保存过程不是为了展示操作数量，而是让结论可追溯。若某次标签依据缺失，最终结果也应当谨慎解释。一个能够回答每步为什么这样判断的记录，比只剩最后一行候选提交更适合技术调查。

如果发现判定规则本身有误，应修正规则并重新核对必要步骤，不要为了保留已有进度继续沿错误前提搜索。此前材料仍可作为调查历史，但不能无条件继承为新判定的证据。将规则版本与结果对应，能够避免后来混淆两轮不同搜索。效率不只是减少运行次数，也包括尽早停止传播不可靠判断，让后续工作建立在真实条件上。

候选提交指出变化位置，不自动解释全部原因

工具给出候选以后，应查看相关改动与实际代码关系，验证它如何影响目标行为。一个提交可能包含多个变化，甚至只是暴露了更早存在的问题。不能把提交作者或一句提交说明当成根因证据。需要结合最小输入、前后结果与接口契约形成解释。历史定位帮助缩小阅读范围，根因分析仍然需要技术推理与针对性验证。

可以在候选前后重新运行同一有限测试，确认变化边界成立，再检查具体差异。若存在合并或其他复杂历史关系，应保留相应限制，不把一条线性故事强加给材料。修复方案也应围绕真实契约，而不是无条件撤销整份提交。回退可能影响其他功能，只有理解变化机制以后，才能选择与问题范围相符的处理，并验证所需行为恢复。

测试接口变化时，不要暗中改变判断对象

历史版本的命令参数或输出格式可能不同。若为了运行同一测试而增加适配层，应明确它只转换调用方式，还是也改变了原本研究的语义。一个过度宽松的适配层可能吞掉差异，让所有版本看起来一致；一个过度严格的适配层又可能将接口演进误判为业务缺陷。应当保留适配理由，并用已知端点验证它仍回答原来的问题。

如果目标属性在某个历史区间尚不存在，可能需要重新选择有意义的端点，而不是强行让每个版本套用后来才出现的契约。搜索范围与问题定义应相互一致。限定路径或历史范围也需要理由，不能为了加快过程随意排除可能影响结果的变化。缩小范围可以提高效率，但范围之外的条件仍可能与行为有关，报告应知道自己作出了哪些选择。

结束搜索后恢复清楚的工作状态

历史调查会改变当前检出的版本与相关会话状态。结束时应按工具文档恢复到明确位置，确认后续编辑与运行基于哪份材料，避免把临时调查状态当作日常开发状态。未提交工作应在开始前就妥善保留，调查不应以丢失当前改动为代价。文章中的原则是限定自有本地范围，并让每个状态变化都有清楚来源，不建议在真实部署目录中随意切换历史。

最终记录可包含属性定义、端点、判定脚本、跳过范围、候选与原因验证。以后回归测试应保护被定位的契约，而不是只保存一条提交编号。二分最有效的前提，是每个好坏判断都真实、稳定并且可比较。让判定先成立，再让工具缩小范围，才能把一次快速历史搜索变成可核查的技术结论，而不是一个精确外观下仍然含糊的猜测。

延伸阅读

• Git — git bisect 官方手册