你可能会说
把这条分支并回主分支,冲突帮我解一下
把一条分支上的改动并回到另一条分支里
大白话解释
合并就是两条岔开的路重新汇到一起。你在分支上把功能做完了,要把它并回主线,让所有人都用得上,这个动作就叫合并。
大多数时候合并很安静,机器几秒钟就完成了。但当两条分支改了同一个文件的同一段代码,机器不知道该听谁的,就会停下来让你决定,这就是冲突。
所以合并不是简单的复制粘贴,它是在把两段历史接到一起,接得好不好,取决于冲突处理得对不对。
什么时候会遇到
- 功能开发完,提了合并请求,等同事评审后点下合并按钮。
- 本地拉取最新代码时提示有冲突,需要手动决定保留哪一版。
- 合并后测试挂了,回看发现是合并时选错了某一边的写法。
- 主线一直在更新,你的分支落后太多,需要把主线合并进来再继续。
- 让 AI 助手帮你解决冲突,需要它先解释两边各自改了什么。
可以直接对 Agent 说
「我这个分支和主分支有冲突了,先告诉我冲突文件里两边分别改了什么,再给出合并方案,我确认后你动手」
「帮我把主分支最新的改动合并进我当前的分支,冲突的地方逐条解释给我听」
「合并完成后帮我跑一下测试,如果有失败的,看看是不是这次合并引入的」
正文里带下划线的词,是本站其它词条的入口;这一篇自动链了 3 个相关术语。
最容易想岔的地方
常见的错误理解: 合并就是把两边的文件放一起,谁新用谁的
更准确的理解: 代码不是文件。同一份文件里两边改的是不同函数,合并能自动完成;改的是同一行才叫真冲突,得人来判断留哪边
常见的错误理解: 解决冲突时选「接受当前分支」最省事
更准确的理解: 一律选一边,等于把另一边的改动悄悄删掉。每一处冲突都要看明白是谁改的、为什么改,再决定
测一下:真遇到了你会怎么处理
单选 · 选完立刻看解释
你要把功能分支合回主分支,Git 提示两个分支改了同一文件的同一段。
下一步该怎么做?
-
冲突是 Git 判断不了的部分 —— 两边都是合理的修改,只有你知道业务上要留哪个。
-
这会静默丢掉别人的工作。除非你确认对方那部分确实不要了,否则不能这么选。
-
两边已有的工作都会丢,而且下次合并大概率还是会撞在同一个位置。
题目只考「这个场景下的第一反应」,不考名词背诵 —— 合并的定义在上面已经讲过了。