连上实验机，先确认什么
进入一个正处于"合并中"的仓库，第一件该做的事是【0】。
怎么证明冲突真的解决了
最可靠的证据是【0】。
解决完成后，那次提交长什么样
合并冲突解决之后产生的提交，和普通提交有什么不同？运行下面这段程序： g = {'3f2a91c': [], '7b4e2d0': ['3f2a91c'], 'a1c5f83
看清这次合并卡在哪几个文件
场景：~/proj 里一次合并做到一半停住了，工作区正处在「合并中」。 任务：先弄清这次合并有哪些文件还没解决；然后打开 config.txt 的冲突块，读上半段（你当前分支这一侧）的 PORT 值，到 ~/对照表.txt 里查它对应的标记
读出对方那一侧的内容
场景：~/proj 里同一种未完成的合并。 任务：这次读 config.txt 冲突块的下半段（被合并进来的 hotfix 那一侧）的 PORT 值，到 ~/对照表.txt 里查它对应的标记。 （判分只看你在受控容器里那个仓库的状态：找东西
把冲突解掉并完成这次合并
场景：~/proj 里合并卡在 config.txt 上。 任务：编辑冲突文件，删掉全部标记行、留下你认为正确的内容；告诉 Git 这个文件已解决；完成这次合并提交。改好运行 ~/check。 （判分只看你在受控容器里那个仓库的状态：找东西
中途撤退：把合并整个放弃掉
场景：~/proj 里又有一次合并卡住了，这次你决定先不解决它。 任务：把这次合并整个放弃掉，让工作区回到合并开始之前的样子（不要手工改文件）。改好运行 ~/check。 （判分只看你在受控容器里那个仓库的状态：找东西类到 ~/对照表.tx
交付：独立解决一次真实冲突
场景：~/proj 里两条分支（main 和 hotfix）都改了同一份 config.txt，可能不止一处冲突。 任务：站在 main 上自己发起合并（git merge hotfix），处理掉全部冲突，确认没有残留标记之后完成合并提交。
⚠️ 历史长了，哪种找法最不划算
仓库里已经有几千次提交，要定位某次改动，最不划算的做法是【0】。
想知道"这一行是谁改的"
历史长了，一条条翻不动 一条条翻 直接筛 要查出某个文件某一行最后是被谁、哪次提交改的，用【0】。