合并Merge
你可能会说
我在另一边试的功能成了，怎么把它并回正式版本？
合并是把另一条修改路线上的已保存改动放进当前路线的操作。例如功能完成后，可以把功能路线合回主版本。两边都改到同一处时，Git 会提示内容冲突，需要决定保留什么、清理提示标记并重新检查。
你可以这样告诉 AI Agent
请把这个功能分支合并到目标分支。先查看冲突两侧各自要保留什么，解决后确保没有冲突标记，再运行相关测试。完成后说明合并结果和测试结果，不要用“任选一边”的方式处理。
什么时候用
- 功能分支已经完成并通过测试后，再合回主版本main
- 合并前先确认自己站在准备接收改动的分支上main
- 出现冲突时逐处理解两边改动，再决定最终结果<<<<<<< HEAD标题：小狸的主页=======标题：小狸的摄影主页>>>>>>> feature
- 合并完成后重新运行项目，确认两边功能仍然正常编辑最终内容→git add→git commit
什么时候不用
- 没有确认当前分支就开始合并，导致改动进入错误位置功能分支仍存在错误→ merge →main 包含同一错误未验证的改动合入 main，会增加发布风险
- 把冲突处理成只保留一边，却没有理解另一边的用途
标题：小狸的主页标题：小狸的摄影主页删除双方内容可能移除原有功能 - 冲突标记没有清理完整就保存版本<<<<<<< HEAD
标题：小狸的主页保留冲突标记可能导致代码无法解析 - 看到命令成功就结束，忘记重新运行和测试merge ✓→push ✓→线上报错
组成结构 · Anatomy
<<<<<<< HEAD
<h1>小狸的主页</h1>
=======
<h1>小狸的摄影主页</h1>
>>>>>>> feature/new-nav
从这里开始是冲突区，HEAD 指你当前所在分支的版本
当前分支上这行长什么样，通常是 main 主线的内容
上下两个版本的分界，解冲突时要一起删掉
被合进来的那条分支上这行长什么样
冲突区到此为止，标着内容来自哪条分支
常见变体 · Variants
快进合并Fast-forward
Updating a3f9c21..e7b2d48
目标分支没有独立的新提交
合并提交Merge Commit
Merge made by the 'ort' strategy.
两侧均有新提交，需要保留合并节点
中止合并merge --abort
git merge --abort
需要放弃当前尚未完成的合并时
典型使用场景
终端 git merge 合回主线
$ git switch main
Switched to branch 'main'
$ git merge feature/new-nav
Merge made by the 'ort' strategy.
index.html | 24 ++++++++++++++-----
1 file changed, 16 insertions(+), 8 deletions(-)
冲突文件里的标记
VS Code 冲突解决按钮
GitHub PR 合并按钮
Git Merge 和 Rebase 有什么区别？
已共享的提交通常用 Merge 整合；尚未共享的个人分支可以在代码评审前用 Rebase 整理成线性历史。
| 对比维度 | Git Merge | Git Rebase |
|---|---|---|
| 提交历史 | 保留完整的分支分叉与汇合记录（快进合并时仅移动分支指针） | 将当前分支的提交在目标基线上逐个重放，生成全新哈希的线性历史 |
| 协作安全 | 不改写已有提交 ID，更适合整合多人已经拉取的历史 | 会生成新的提交 ID；改写共享历史前必须与协作者明确协调 |
| 适用时机 | 合并功能分支到主干，或同步已经共享的团队分支 | 个人分支尚未共享，想在评审前整理历史或同步主干改动 |
延伸阅读 · 权威出处
快速练习