3.13操作⏱ 约 5 分钟

合并分支(git merge)

把支线的成果带回主线

🔎 最后验证 2026-05📚 来源:Git/GitHub 官方文档🧰 Git✅ 110 人学过👁 217 次阅读

为什么学这个

在分支上把新功能做好了,现在把它"汇入"主分支——这就是 git merge。它把两条支线的工作合到一起,完成"开分支 → 干活 → 合并"的完整闭环。

💡 打个比方

合并就像支流汇入主河:新功能分支这条支流积攒的水(改动),汇进 main 这条主河。汇合后,主河就拥有了支流带来的一切。

git merge 分支名 = 把指定分支的改动合并到你当前所在的分支
标准流程:先 git checkout main(站到主线)→ 再 git merge 新功能(把支线并进来)
合并后,新功能分支的文件/改动就出现在 main 上了
合并完,那条用完的功能分支通常可以删掉

完整走一遍:git checkout -b 新功能 → echo 新按钮代码 > 按钮.js → git add . → git commit -m "加按钮" → git checkout main → ls(没有按钮.js)→ git merge 新功能 → ls(按钮.js 回来了!):

模拟终端(自由练习 · 敲错也不会弄坏任何东西)

🎯 小目标:在新分支做一个功能,再切回 main 并用 git merge 把它合并进来

这是一个已初始化好的 Git 仓库(已有一个'初始提交')。试试 git status、git log。

~ $

❓ 测验

把新功能分支合并进 main 的正确顺序是?

进阶:亲手制造并解决一次"合并冲突"

合并不总是顺利。如果两条分支改了同一个文件的同一处,Git 没法替你决定听谁的,就会报合并冲突。下面亲手制造一次并解决它(这是真实协作里几乎必然会遇到的场景):

git checkout -b 改标题 → echo '<h1>新标题A</h1>' > 首页.html → git add . → git commit -m "改成A"
git checkout main → echo '<h1>新标题B</h1>' > 首页.html → git add . → git commit -m "改成B"
git merge 改标题 → ⚠️ 报冲突!cat 首页.html 看到 <<<<<<< 标记
解决:echo '<h1>最终确定的标题</h1>' > 首页.html(删掉标记、留下你要的)

(💡 含 < > 的内容要用引号包住,否则真实终端会把 < 当重定向符报错) 5. git add . → git commit -m "解决合并冲突" → 冲突解决,合并完成

模拟终端(自由练习 · 敲错也不会弄坏任何东西)

🎯 小目标:制造一次合并冲突,看到 <<<<<<< 标记,再手动解决并提交完成合并

这是一个已初始化好的 Git 仓库(已有一个'初始提交')。试试 git status、git log。

~ $

⚠️ 避坑冲突不可怕,看懂三个标记就行

冲突文件里会出现三段标记:<<<<<<< HEAD 到 ======= 之间是你当前分支的内容,======= 到 >>>>>>> 之间是对方分支的内容。你要做的就是:删掉这三行标记,把中间内容改成你最终想要的样子,然后 git add + git commit。别怕,它只是让你来拍板"听谁的"。

🤖 用 AI 巩固这一节

请讲清楚 git merge:什么是 fast-forward 合并、什么是普通合并、什么是合并冲突。重点教我:遇到合并冲突时,该按什么步骤一步步解决?

🔎 来源与核验· 2 条,点开核对

本节每个关键论断都对应一个可追溯的来源 —— 这是本课程"靠谱、不过时"的底线。

「git merge 把指定分支合并到当前分支;能自动合并就生成合并提交」

📚 Git 官方文档 · git-merge✓ 已核验 2026-05

「两分支改动同一处时产生冲突,需手动解决 <<<<<<< ======= >>>>>>> 标记后再提交」

📚 Pro Git(官方中文版)·Git 分支 — 分支的新建与合并(遇到冲突时的分支合并)✓ 已核验 2026-05

✅ 小结

你已经走通了"开分支 → 干活 → 合并"的完整闭环——这是真实团队协作的核心。下一节把这套串成一个"专业工作流",看看高手日常是怎么用的。

下一节 → 专业工作流

都看到这了，打个赏呗！

接下来 · 3.14

专业工作流

继续读下一节 →