怎么证明合并真的成了
要确认一次合并确实完成了，最直接的证据是【0】。
合并成功后，log 里该看到什么
下面这段模拟了合并后的提交图。运行它，看新的分支顶端有几个父提交： def ancestors(g, c): seen = set() st = [c] while st: x = st.pop()
在实验机上开出一条自己的分支
场景：~/proj 是一个仓库，你被分到一个新功能。 任务：先弄清自己现在在哪条分支上，再从这里开出一条叫 feature 的新分支并切过去。改好运行 ~/check。 （判分只看你在受控容器里那个仓库的状态：找东西类到 ~/对照表.txt
在分支上提交，并确认主线纹丝不动
场景：~/proj 里你已经在 feature 分支上了（分支上有两次提交 f1、f2）。 任务：先在 feature 上随便改点东西再提交一次；然后用一条命令同时看两条分支各自指向哪次提交——你会发现主线 main 还停在原地。到 ~/对
把分支合回主线
场景：~/proj 里功能做完了：你在 feature 上，它有自己的提交；主线 main 在你干活期间也往前走过（改的是别的文件，不会冲突）。 任务：切回 main，把 feature 合进来——这次会产生一个合并提交。改好运行 ~/ch
找出那次合并的两个父提交
场景：~/proj 的主线 main 上已经有若干次合并。 任务：找出 main 历史里最近的一次合并提交，查出它的两个父提交；这两个父提交里日期较早的那一次，到 ~/对照表.txt 里查它的提交说明对应的标记。 （判分只看你在受控容器里那
交付：从分出去到合回来，完整走一遍
场景：~/proj 只有主线 main（README 里有一个待办功能：在 app.py 里加一个 hello() 函数）。 任务：完整走一遍分支流程——从 main 开出一条功能分支、在上面完成至少一次提交、再切回 main 把它合并进来
⚠️ 冲突到底为什么会发生
合并时出现冲突，根本原因是【0】。
两边都改了，就一定冲突吗
同一格，两个人都动了 我改的 他改的 同一处两边都动过，Git 【0】。
Git 凭什么知道"这行被改过"
同一格，两个人都动了 我改的 他改的 Git 判断某一行改没改，靠的是【0】。