Git代码合并两大神器：Merge 对决 Cherry-pick，你真的用对了吗？

今天想跟大家扯扯一个老生常谈但又经常被搞混的话题——代码合并这点事儿。

说起合并代码，估计 git merge 大家都用烂了。不过它还有个"兄弟" git cherry-pick，虽然不太起眼，但关键时刻真的能救命。问题是，很多人（包括我之前）经常把这俩搞混，结果把项目历史弄得一团糟，后悔都来不及。

那这俩家伙到底啥区别？什么时候该用哪个？别急，我们慢慢聊。
在这里插入图片描述

在这里插入图片描述

先说说大家最熟悉的 merge。我喜欢把它想象成这样：你的 master 分支是条主河道，然后你在旁边开了条支流（比如 feature 分支）搞开发。等功能做完了、测试也过了，是时候让这条支流回归主河道了。这时候 merge 就派上用场了。

它的思路很简单：把整个分支的历史都给你合并进来，一个不落。

具体怎么干的呢？

你站在 master 上，敲个 git merge feature/user-center，Git 就开始忙活了：

先找到两个分支的"共同祖先"（就是它们分叉的那个点）
把 feature 分支从那之后的所有提交都拿过来，跟 master 的提交一起合并
在 master 上生成一个特殊的合并提交，这家伙有两个"爸爸"——一个指向 master 的最新提交，一个指向 feature 的最新提交

# 标准操作流程，应该都很眼熟
git checkout master
git fetch origin
git pull origin master

git merge feature/user-center
git push origin master

merge 的好处显而易见：

但也有让人头疼的地方：

在这里插入图片描述

现在换个场景。你正在一个复杂的 feature/new-algorithm 分支上折腾，里面有10个提交。突然发现第3个提交（假设是 a1b2c3d）修复了个要命的Bug，生产环境马上就要崩了！

问题是，整个 feature 分支还没搞完，但这个Bug修复必须马上上线。咋办？

这时候 cherry-pick 就像个精准的外科手术刀，专门干这种活。

它的思路更直接：我不要你的分支，我就要你这一个提交，其他的别烦我。

具体操作：

你切到 master，然后 git cherry-pick a1b2c3d，Git就会：

# 精准打击，专治急症
git checkout master
git pull origin master

# 从feature分支"偷"个提交过来
git cherry-pick a1b2c3d 
git push origin master

cherry-pick 的优势：

但坑也不少：

前段时间我们项目就遇到过这种情况：

我在feature/payment分支开发支付功能，写了大概15个提交。突然测试发现生产环境有个计算金额的bug，而我在第8个提交里正好修复了这个问题。

这时候支付功能还没开发完，但这个bug必须马上修复。我就用了cherry-pick：

git checkout master
git cherry-pick 8a7b6c5  # 第8个提交的ID
git push origin master

这样就把bug修复快速上线了，而不用等整个支付功能开发完。

在这里插入图片描述