如何让git cherry-pick使用fast forward快进合并技术

核心原因 #

首先要明确：fast-forward快进机制是git merge专属的优化逻辑，git cherry-pick从设计上就永远不会触发快进，两者的底层运行逻辑完全不同：

• 执行git merge testing时，Git会先计算两个分支HEAD的最近共同祖先，判断发现当前master分支的HEAD提交本身就在testing分支的提交历史链路中（是testing分支两个提交的直系祖先），因此不需要做任何文件内容的三方合并，只需要把master的分支指针直接移动到testing的HEAD位置即可完成合并，全程不会改动文件内容，自然不会产生冲突。
• 执行git cherry-pick testing时，Git的处理逻辑是提取testing分支最新单个提交的改动补丁，在当前master的HEAD位置重新应用这个补丁，最终生成一个全新哈希的独立提交，根本不会判断当前HEAD和目标提交是否存在直系路径。

你遇到冲突的直接原因是补丁上下文不匹配：
你要拣选的testing最新提交，它的直接父节点是testing分支上的第一次提交（文件内容为MASTER - 1st commit : TESTING 1st commit），cherry-pick应用补丁时会执行三方比对：

• 合并基准（共同祖先）：上述testing分支第一次提交的文件内容
• 当前分支（ours，master）的文件内容：MASTER - 1st commit
• 目标提交（theirs，testing最新提交）的文件内容：MASTER - 1st commit : TESTING 1st commit : TESTING 2nd commit

Git计算补丁时发现，目标提交相对于父节点的改动是在行尾追加 : TESTING 2nd commit，但当前master分支的对应行根本不存在 : TESTING 1st commit这段内容，找不到补丁匹配的上下文位置，就会直接报合并冲突——本质是你只拣选了连续提交链上的最后一个提交，跳过了它依赖的前序改动，上下文自然对不上。

对应正确操作 #

根据你的实际需求选对应方式即可：

• 如果你的目标是把testing分支的所有提交完整合入master，直接用git merge testing即可，会自动触发快进，无任何冲突，完全符合预期，这种场景不需要用cherry-pick。
• 如果你的目标是把testing分支上的连续多个提交按顺序拣选到master，不要只指定最后一个提交，使用范围拣选语法：git cherry-pick master..testing，Git会按提交先后顺序依次应用testing上从master分叉后的所有提交，每个补丁的上下文都能匹配，不会产生冲突。
• 如果你的目标就是跳过testing的第一个提交，只把第二个提交的改动合入master，那当前出现的冲突是预期行为，手动编辑文件解决冲突后执行git cherry-pick --continue完成提交即可，不存在无冲突的捷径——毕竟你主动跳过了前序依赖改动，补丁本来就缺少应用基础。

注意：不要混淆merge和cherry-pick的定位，merge的核心是合并分支历史，cherry-pick的核心是复制指定提交的改动重放，后者不会自动关联整条提交链路。

内容的提问来源于stack exchange，提问作者ansme