diff --git a/translated/tech/20221122.0 ⭐️ Find bugs with the git bisect command.md b/published/20221122.0 ⭐️ Find bugs with the git bisect command.md similarity index 56% rename from translated/tech/20221122.0 ⭐️ Find bugs with the git bisect command.md rename to published/20221122.0 ⭐️ Find bugs with the git bisect command.md index 948e255712..f870c884c0 100644 --- a/translated/tech/20221122.0 ⭐️ Find bugs with the git bisect command.md +++ b/published/20221122.0 ⭐️ Find bugs with the git bisect command.md @@ -3,34 +3,38 @@ [#]: author: "Dwayne McDaniel https://opensource.com/users/dwaynemcdaniel" [#]: collector: "lkxed" [#]: translator: "chai001125" -[#]: reviewer: " " -[#]: publisher: " " -[#]: url: " " +[#]: reviewer: "wxy" +[#]: publisher: "wxy" +[#]: url: "https://linux.cn/article-15310-1.html" -使用 git bisect 命令定位首次引入错误的提交 +使用 Git bisect 命令定位首次引入错误的提交 ====== -你是不是有过这样的经历:发现代码中有 错误 bug ,但不知道这个错误是什么时候第一次引入的。这有可能是因为,某个人提交了一份有错误的代码,但没有在他的 Git 提交 commit 消息中声明这个错误。这个错误可能已经存在了几周、几个月甚至几年,这意味着你需要搜索数百或数千个提交,才能找到问题何时出现的。而 `git bisect` 命令能够完美地解决这个问题! +![][0] -`git bisect` 命令是一个强大的工具。你可以给 `git bisect` 命令一个范围,一端是一个已知的好状态,另一端是一个已知的坏状态。它会自动地确认当前范围的中点,在这个中点上进行测试,然后要求你告诉它那次提交是一个 好提交 good commit 还是一个 坏提交 bad commit ,然后它会重复这一“二分查找”的过程,直到你找到首次引入错误的那一次提交。 +> Git 的 bisect 工具通过快速识别坏的提交,节省了时间和精力。 + +你是不是有过这样的经历:发现代码中有 错误 bug ,但不知道这个错误是什么时候引入的。这有可能是因为,某个人提交了一份有错误的代码,但没有在他的 Git 提交 commit 消息中声明它。这个错误可能已经存在了几周、几个月甚至几年,这意味着你需要搜索数百或数千个提交,才能找到问题何时出现的。而 `git bisect` 命令能够完美地解决这个问题! + +`git bisect` 命令是一个强大的工具。你可以给 `git bisect` 命令一个范围,一端是一个已知的好状态,另一端是一个已知的坏状态。它会自动地确认当前范围的中点,在这个中点上进行测试,然后要求你确定那次提交是一个 好提交 good commit 还是一个 坏提交 bad commit ,然后它会重复这一“二分查找”的过程,直到你找到首次引入错误的那一次提交。 ![Image of Zeno's paradox of Achilles.][1] -这个“数学”工具是利用“二分查找”来找到错误之处的。`git bisect` 命令通过**查看中点**,然后由你来决定它是提交列表的新起点(即 bad commit )还是新终点(即 good commit),进而来缩小查找范围,如此在几次查找中你可以就能定位到有错误的提交。即使你有 10,000 个提交要检查,最多只需要 13 次查找,就能很快地定位到首次引入错误的提交。 +这个“数学”工具是利用“二分查找”来找到错误之处的。`git bisect` 命令通过**查看中点**,然后由你来决定它是提交列表的新起点(即 “坏提交” )还是新终点(即 “好提交”),进而来缩小查找范围,如此在几次查找中你可以就能定位到有错误的提交。即使你有 10,000 个提交要检查,最多只需要 13 次查找,就能很快地定位到首次引入错误的提交。 -- commit 1 bad <> commit 10,000 good => commit 5,000 is bad -- commit 5,000 bad <> commit 10,000 good => commit 7,500 is good -- commit 5,000 bad <> commit 7,500 good => commit 6,250 is good -- commit 5,000 bad <> commit 6,250 good => commit 5,625 is bad -- commit 5,625 bad <> commit 6,250 good => commit 5,938 is bad -- commit 5,938 bad <> commit 6,250 good => commit 6,094 is good -- commit 5,938 bad <> commit 6,094 good => commit 6,016 is bad -- commit 6,016 bad <> commit 6,094 good => commit 6,055 is good -- commit 6,016 bad <> commit 6,055 good => commit 6,036 is bad -- commit 6036 bad <> commit 6055 good => commit 6046 is bad -- commit 6,046 bad <> commit 6,055 good => commit 6,050 is bad -- commit 6,050 bad <> commit 6,055 good => commit 6,053 is good -- commit 6,053 bad <> commit 6,055 good => commit 6,054 is good +1. 提交 1 坏 <> 提交 10,000 好 => 提交 5,000 是坏的 +2. 提交 5,000 坏 <> 提交 10,000 好 => 提交 7,500 是好的 +3. 提交 5,000 坏 <> 提交 7,500 好 => 提交 6,250 是好的 +4. 提交 5,000 坏 <> 提交 6,250 好 => 提交 5,625 是坏的 +5. 提交 5,625 坏 <> 提交 6,250 好 => 提交 5,938 是坏的 +6. 提交 5,938 坏 <> 提交 6,250 好 => 提交 6,094 是好的 +7. 提交 5,938 坏 <> 提交 6,094 好 => 提交 6,016 是坏的 +8. 提交 6,016 坏 <> 提交 6,094 好 => 提交 6,055 是好的 +9. 提交 6,016 坏 <> 提交 6,055 好 => 提交 6,036 是坏的 +10. 提交 6,036 坏 <> 提交 6,055 好 => 提交 6,046 是坏的 +11. 提交 6,046 坏 <> 提交 6,055 好 => 提交 6,050 是坏的 +12. 提交 6,050 坏 <> 提交 6,055 好 => 提交 6,053 是好的 +13. 提交 6,053 坏 <> 提交 6,055 好 => 提交 6,054 是好的 对于上面这个例子,我们能知道 10,000 个提交中的第一个错误提交是第 6053 次提交。对于 `git bisect` 命令,最多需要几分钟就能完成检索。但是如果要一个一个查找每个提交是否错误,我甚至无法想象需要多长时间。 @@ -52,7 +56,11 @@ Git 检查中间的提交,并等待你声明这次提交是一个好提交还 ``` $ git bisect good -## or +``` + +或 + +``` $ git bisect bad ``` @@ -71,10 +79,11 @@ via: https://opensource.com/article/22/11/git-bisect 作者:[Dwayne McDaniel][a] 选题:[lkxed][b] 译者:[chai001125](https://github.com/chai001125) -校对:[校对者ID](https://github.com/校对者ID) +校对:[wxy](https://github.com/wxy) 本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出 [a]: https://opensource.com/users/dwaynemcdaniel [b]: https://github.com/lkxed [1]: https://opensource.com/sites/default/files/2022-11/beyondgit.paradox.png +[0]: https://img.linux.net.cn/data/attachment/album/202212/02/092549j2o7h9cif3hcu34z.jpg \ No newline at end of file