Git bisect输出合并基准同时为bad和good意味着什么？

我刚执行了一次耗时的Git bisect操作，得到如下Git输出：

The merge base ec879c71aa41065af101d1cce61966417e8d53c9 is bad.
This means the bug has been fixed between ec879c71aa41065af101d1cce61966417e8d53c9 and [54abe781c482f51ff4ff534ebaba77db5bd97442 5f93eceab193e255b87e06348b69148647c9d2d9 ea865346a07d965645b520478283d5f003c45227 ec879c71aa41065af101d1cce61966417e8d53c9].

（这些提交来自Nixpkgs，查看相关历史可能有帮助。）

为节省横向空间，我用字母A到D指代提交，简化后输出如下：

The merge base A is bad.
This means the bug has been fixed between A and [B C D A].

根据此前的了解，通常此消息表示所二分的bug继承自其他分支，且已在该分支中修复——即bug存在于A中，但后续已修复，不再出现在B、C、D以及...A中？

这种情况如何解释？

以下是git bisect log的输出：

git bisect start
# status: waiting for both good and bad commits
# bad: [b04b3345f16716f7289724286cdc8474d4758a41] Merge pull request #195082 from cmm/system76-scheduler
git bisect bad b04b3345f16716f7289724286cdc8474d4758a41
# status: waiting for good commit(s), bad commit known
# good: [ec879c71aa41065af101d1cce61966417e8d53c9] Merge staging-next into staging
git bisect good ec879c71aa41065af101d1cce61966417e8d53c9
# good: [5f93eceab193e255b87e06348b69148647c9d2d9] Merge pull request #228171 from bcdarwin/unbreak-pybids-nipype-heudiconv
git bisect good 5f93eceab193e255b87e06348b69148647c9d2d9
# good: [54abe781c482f51ff4ff534ebaba77db5bd97442] Merge pull request #228465 from linsui/python-lsp-ruff
git bisect good 54abe781c482f51ff4ff534ebaba77db5bd97442
# good: [ea865346a07d965645b520478283d5f003c45227] Merge pull request #229005 from r-ryantm/auto-update/protoc-gen-validate
git bisect good ea865346a07d965645b520478283d5f003c45227
# bad: [19ca45e39f1dd7ec9f35cf836c7e7a3ff7f18304] vulkan/update-script: always update to latest upstream tags
git bisect bad 19ca45e39f1dd7ec9f35cf836c7e7a3ff7f18304
# bad: [1e9a1505d5fe92093ca36c41f9bd6279c07fe4d2] Merge branch 'staging' into staging-next
git bisect bad 1e9a1505d5fe92093ca36c41f9bd6279c07fe4d2
# skip: [b394a31dd2d715d0ac71e1e3dee2a1076e512d74] Merge pull request #226253 from trofi/fluidsynth-dev-and-man-output
git bisect skip b394a31dd2d715d0ac71e1e3dee2a1076e512d74
# skip: [b58f4b8439f7f6234f4e66343a450aabe90df590] Merge #226730: python310Packages.watchdog: 2.3.0 -> 2.3.1
git bisect skip b58f4b8439f7f6234f4e66343a450aabe90df590
# skip: [3c2398e35866d75730bf48a05027b1b7bfb00e4c] Merge staging-next into staging
git bisect skip 3c2398e35866d75730bf48a05027b1b7bfb00e4c
# skip: [8af3c74004d5a37e061646d3ff1370c7d6cca446] Merge staging-next into staging
git bisect skip 8af3c74004d5a37e061646d3ff1370c7d6cca446
# bad: [804dc945940ba1bb75994f49d6cd6397b94eb596] neovim-unwrapped: add debug output
git bisect bad 804dc945940ba1bb75994f49d6cd6397b94eb596
# bad: [a08d6979dd7c82c4cef0dcc6ac45ab16051c1169] Merge pull request #218973 from sumnerevans/matrix-synapse-1.78
git bisect bad a08d6979dd7c82c4cef0dcc6ac45ab16051c1169

问题解析 #

从你的git bisect log可以看出，二分过程中标记的提交存在分支路径冲突：

1. 你最初标记旧提交A（ec879c7）为good，但后续标记的多个bad提交（如b04b334、19ca45e等）都是A的后代，这说明A本身实际带有bug——你最初的标记错误了。
2. 而你标记为good的B/C/D（54abe78、5f93ece、ea86534）属于另一条分支，这条分支从A之后的节点分叉，并且在该分支内修复了bug，所以这些提交没有问题。

Git输出的消息实际含义是：

• 所有标记提交的共同祖先A存在bug；
• 修复操作发生在A到B/C/D所在分支的路径上；
• 你标记为bad的那些提交属于继承了Abug的主分支（或另一条未合并修复的分支），因此仍保留bug。

消息里出现A同时在"修复区间"两端，是Git在多分支场景下的模糊表述，核心是A是bug的起点，而B/C/D所在分支完成了修复，而你关注的主分支没拿到这个修复。

解决建议 #

• 重新验证A的状态：checkout提交A进行测试，确认它是否真的存在bug；
• 修正bisect标记：如果A确实有bug，执行git bisect bad ec879c71aa41065af101d1cce61966417e8d53c9，然后继续bisect，聚焦到B/C/D分支中的修复提交；
• 排查标记错误：如果A是正常的，说明你标记的某些bad提交有误，需要重新测试这些提交的状态，修正标记后再继续二分。

内容的提问来源于stack exchange，提问作者ash