交付：一次完整的历史考古与恢复
这是本条路线的最终作品。把前面的代码合起来，一次验完五条： 历史一共 7 次提交 出问题那行归 d44f6a1，它排第 4 那次提交的改动是 +2 −0 二分同样找到 d44f6a1，测了 3 次 revert 之后历史 8 次，reset
上真机之前先确认什么
要在实验机上做历史考古，动手前先确认【0】。
怎么证明回滚真的做对了
回滚之后，最可靠的验证是【0】。
回滚之后历史该是什么样
用 revert 撤销那次引入 bug 的提交之后，历史长度和那次提交还在不在？运行下面这段程序： def revert(hist, target): """造一个反向提交接在最后，原来那次一个都不动&
找出某一行是谁改的
场景：~/proj 的 app.py 里有一行看起来很可疑（README 里写了是第几行）。 任务：查出那一行最后是被哪次提交改的，到 ~/对照表.txt 里查那次提交的说明对应的标记。 （判分只看你在受控容器里那个仓库的状态：找东西类到
看清某次提交到底改了什么
场景：~/proj 的 README 里写了一个可疑的提交 id。 任务：查出那次提交具体改了什么——它新增的行里有一行注释「# tag: T-xxxx」，到 ~/对照表.txt 里查那个 tag 对应的标记。 （判分只看你在受控容器里那个
用二分找出弄坏功能的那次提交
场景：~/proj 里有个自检脚本 bash selftest.sh，现在跑是失败的，但很早以前是好的（README 写了哪次提交是已知好的）。 任务：用二分的办法找出第一次让它失败的那次提交，到 ~/对照表.txt 里查那次提交的说明对应
把一次错误的提交安全地撤销掉
场景：~/proj 里 README 写了是哪次提交引入了问题（自检 bash selftest.sh 现在失败）。这次提交已经推出去、别人也拉过了。 任务：用不改写已有历史的方式把那次改动撤销掉（历史只能变长不能变短），让自检重新通过。改
交付：在真机上找出并撤销那次提交
场景：~/proj 的自检 bash selftest.sh 坏了，README 只写了哪次提交是已知好的。 任务：完整走一遍——找出是哪次提交弄坏的、看清它改了什么、用不改写历史的方式撤销它，最后确认自检重新通过。改好运行 ~/check
⚠️ 代码规范到底解决什么
团队定代码规范，最主要是为了【0】。