三种状态，哪种能提交
can_commit 判断当前能不能完成这次合并提交：文件里还有标记 → 不行；标记删干净但没 add → 也不行；删干净且 add 了 → 可以。运行下面这段程序： def is_marker(line): return line
合并完成后主线上有几次提交
合并顺利完成后，主线的历史里能追溯到几次提交？（承上一条路线那张图：两边各自往前走过，这次是三方合并。）运行下面这段程序： g = {'3f2a91c': [], '7b4e2d0': ['3f2a9
⚠️ 写一个 can_commit
补全 can_commit(lines, staged)：文件里还有标记就不行；没有标记时才看 staged。 验两种情形并拼起来输出：还有标记但已经 add 过、标记已删干净且 add 过。
⚠️ 三种状态各判一次
用你的 can_commit 判三次：有标记且没 add、无标记但没 add、无标记且已 add。 三个结果拼起来输出（按上面的顺序）。
⚠️ 从冲突到可提交，完整走一遍
把整个流程串起来，输出三样：带标记的行数 / 解决后的行数 / 解决并 add 之后能不能提交。
减少冲突最管用的一条
要让冲突变少，最有效的做法是【0】。
"明确归属"为什么管用
约定"某块代码主要由某人负责"能减少冲突，因为【0】。
⚠️ 统一格式化能减少什么冲突
团队统一用一个格式化工具，能减少的是【0】。
早合并和晚合并，冲突差多少
同样两条分支，如果分支只做了第一步就合回来（只改了 HOST），和拖到现在才合，冲突数各是多少？运行下面这段程序： def classify(b, o, t): if o == t: return "sam
"都动过"和"真冲突"差几行
数两个数：两边都动过的行数，和其中真正冲突的行数。运行下面这段程序： def classify(b, o, t): if o == t: return "same" if o == b: