TRAE-AI编程
当你在 Git 里开发新功能时，往往会从 main 切出一个功能分支，等写完再并回去。真正卡住新手的，不是「怎么合并」，而是「用哪种合并才不会把提交历史搞乱、不会平白多出冲突」。Git 合并分支最稳的做法只有一条：本地已提交的前提下，想保留完整历史就用 git merge，想让历史像一条直线就用 git rebase，只想要其中某几个提交就用 git cherry-pick。本文基于 Git 2.4x 版本实测，把这三种方式从命令、输出到常见冲突一次讲清，并附一张选型表，你看完就能照着选、照着敲。
一、先看结论
三种合并方式的取舍，先看这张表就能做决定：
| 方式 | 适用场景 | 提交历史形态 | 主要风险 |
|---|---|---|---|
| git merge | 合并公共分支、团队协作保留完整记录 | 保留分叉，生成一次合并提交 | 历史较碎，可能出现多个合并提交 |
| git rebase | 整理自己的本地分支，追求线性历史 | 把提交接到目标分支之后 | 改写了提交，禁止对已推送分支 rebase |
| git cherry-pick | 只把某几个提交搬到别的分支 | 仅新增选定的那几个提交 | 容易重复提交，需手动解上下文冲突 |
一句话选型：公共分支合并用 merge，个人本地分支整理用 rebase，跨分支摘个别提交用 cherry-pick。下文把每条命令、预期输出和踩坑点都拆开讲。
二、git merge 直接三方合并
git merge 是 Git 合并分支里最常用、也最安全的合并方式。它会把两个分支的提交历史「三方合并」——以它们共同的祖先提交为基准，算出差异后生成一个新的合并提交（merge commit）。
先确认当前分支已切到目标分支，再执行合并：
# 切到要并入的分支，例如 main
git switch main
# 把 feature 分支合并进来
git merge feature
如果两边改的是不同文件、没有冲突，Git 会直接生成合并提交并打开编辑器让你填合并说明。执行 git log --oneline --graph 你能看到一条带分叉再汇合的历史线。
* 8a1c2d3 (HEAD -> main) Merge branch \'feature\' into main
|\\
| * 3f9e0a1 实现登录校验
* | 7b2d4c5 更新首页样式
|/
* 1a0b9c8 初始化项目上面这段就是合并成功后的实际输出结构（预期结果，本机未执行，依据 Git 官方文档的三方合并行为）。如果你的功能分支从未推送到远程、只是自己本地用，merge 几乎不会出问题。相关基础命令先过一遍 Git 教程 会更顺手。
万一真的遇到冲突，也别慌：Git 会在冲突文件里用 <<<<<<<、\n=======、\n>>>>>>> 三组标记把两边改动都留下来。你手动删掉标记、保留想要的版本，再 git add 文件名 和 git commit 就完成合并。冲突不可怕，它只是在提醒你「这段两个人改了同一处」，逐个文件解决即可。怕忘的话，先把对方的改动另存一份，再决定留哪版。
三、git rebase 变基合并
git rebase 是 Git 合并分支里追求整洁历史的做法，思路和 merge 相反：它不生成合并提交，而是把「当前分支的提交」一个个摘下来，重新接到目标分支的最新提交之后，让历史看起来像一条直线。
# 在 feature 分支上，把它变基到 main 最新提交之后
git switch feature
git rebase main变基后历史变成：
* 3f9e0a1 实现登录校验
* 7b2d4c5 更新首页样式
* 1a0b9c8 初始化项目（main 的起点）注意分支管理上的一点：rebase 会改写提交的哈希值。所以黄金规则是——只对自己还没推送、或只有你一个人在用的本地分支 rebase；一旦分支已经推到远程且别人也在用，rebase 会让大家的本地历史对不上，引发大规模冲突。想看清分支关系，可以回头看 Git 分支管理。
四、git cherry-pick 拣选提交
有时你只想把别的分支上的「某一个或几个提交」搬过来，而不是整个分支合并，这时用 git cherry-pick。它像复印机：把指定提交的内容复制一份，作为一个新提交贴到当前分支。
# 把提交 3f9e0a1 单独搬过来
git switch main
git cherry-pick 3f9e0a1常见场景：你在 feature 分支顺手写了一个很小的修复，但 feature 还不能直接合，而这个修复又急着上线，就可以单独 cherry-pick 过去。命令参数和更多组合方式可以翻 Git 速查手册。
cherry-pick 也可能遇到冲突，因为它把提交「重放」到新分支时，上下文可能和原分支不一样。冲突时同样先解决文件里的标记，再 git add 和 git cherry-pick --continue。如果中途发现拣错了，用 git cherry-pick --abort 随时退出，分支回到操作前的状态。它的核心价值是「只拿提交本身、不碰其余历史」。
五、三种方式横向对比与选型
把三种方式放回同一个工作流里看，差异就更清楚了：
| 维度 | git merge | git rebase | git cherry-pick |
|---|---|---|---|
| 是否改变历史 | 否 | 是（改写哈希） | 是（新增提交） |
| 历史可读性 | 保留全貌，略碎 | 线性，最干净 | 只多几个点 |
| 团队协作安全 | 高 | 低（已推送禁用） | 中 |
| 典型用途 | 合并公共分支 | 整理本地分支 | 跨分支摘提交 |
实际落地时有一个简单判断：功能分支往 main 合，一律用 merge；你自己的本地分支想整洁，本地用 rebase 整理；只想要别人的某一个提交，就用 cherry-pick 精确搬运。三者并不冲突，常常在同一个仓库里轮流出现——比如先在本地 rebase 整理，再往 main merge，最后把某个修复 cherry-pick 到线上热修分支。
5.1 什么时候绝对不要用 rebase
只要分支已经 git push 到远程、并且有其他人在基于它工作，就不要用 rebase。改写历史后，同事拉取时会得到一堆「你的版本和远程版本分叉」的冲突，需要他们手动 rebase 你的新哈希，极易出错。这也是团队约定里「公共分支禁止 rebase」的原因。
5.2 踩坑清单
| 现象 | 原因 | 修复 |
|---|---|---|
| rebase 中途冲突卡住 | 两个分支改了同一段代码，引发分支冲突 | 解决冲突后 git add <文件>，再 git rebase --continue |
| cherry-pick 后内容重复 | 同一提交被拣选了两次 | 用 git log 找到重复提交，git revert <哈希> 撤销其中一个 |
| merge 后历史一团乱麻 | 反复在公共分支 merge | 约定「往公共分支只 merge、不 rebase」，本地整理用 rebase |
不同团队的协作流程差异很大，Git 工作流 里有更完整的分支模型可参考。
验证合并是否真的干净
合并完别急着推送，先运行 git log --oneline --graph 检查历史线是否符合预期：merge 应看到分叉再汇合，rebase 应看到一条直线。再验证工作区没有遗留的冲突标记——可以用 grep -rn \'<<<<<<<\' . 全局检查一遍，确认没有 <<<<<<< 残留。如果冲突标记没清干净就提交，后续合并会反复失败；遇到这种情况，回到对应文件手动修掉标记，再 git add 即可。把「运行检查 → 验证结果 → 失败修复」养成习惯，能少吃很多回滚的苦。
总结
Git 合并分支不是只有一种做法：git merge 保留完整历史、最稳；git rebase 让历史变直线、只适合本地；git cherry-pick 只搬指定的个别提交。记住三条要点：公共分支用 merge、本地整理用 rebase、摘单个提交用 cherry-pick；已推送的分支永远不要 rebase。下一步建议把这三种方式在同一个仓库里各练一遍，感受历史线从分叉到直线的区别。
延伸学习
想把 Git 完整学一遍，可以按这个顺序来：
常见问题
Q：git merge 和 git rebase 到底选哪个？
A：看分支是不是公共的。公共分支（如 main）合并用 git merge，能保留每个人真实的提交记录；自己本地的功能分支想整洁一点，就用 git rebase 整理成直线。一句话：merge 保真，rebase 美观。
Q：rebase 中途冲突了怎么处理？
A：先手动解决文件里的冲突标记，然后 git add 文件名，再执行 git rebase --continue 继续。想放弃整个过程就 git rebase --abort，分支会回到 rebase 前的状态，不会丢东西。
Q：已经推送到远程的分支还能 rebase 吗？
A：强烈不建议。rebase 会改写提交哈希，推上去后同事拉取会冲突不断。如果只有你一个人用、且确定没人基于它工作，可以先 git push --force-with-lease 强制更新，但公共分支一律用 merge 更安全。
