基于master分支git cherry-pick时，冲突为何包含更早提交的变更？

嘿，这个场景我太熟悉了！咱们来拆解一下你碰到的问题：你从master切了新分支，尝试cherry-pick staging上的第一个目标提交，结果不仅冲突，还带出了这个提交之前的变更，大概率是这几个原因导致的：

• 目标提交依赖staging分支的前置变更
  你以为要迁移的是一个独立的提交，但实际上这个提交是基于staging分支里更早的修改做的。举个例子：假设staging上先有提交A修改了utils.js里的某个函数，然后你要cherry-pick的提交B是在A的基础上，调用了这个修改后的函数。当你在基于master的新分支上cherry-pick B时，master分支里没有提交A的变更，Git找不到B修改的基准上下文，就会把A的变更也当成B的一部分拉进来，同时因为代码上下文不匹配，直接触发冲突。

• 误选了包含前置变更的合并提交
  如果你cherry-pick的哈希值对应的是一个合并提交（就是staging分支里合并其他分支生成的提交），Git默认会尝试把合并提交的所有变更都应用进来，这就会包含合并之前的一系列变更。你可以用git log --oneline staging检查一下目标提交的类型，合并提交会显示两个父哈希值。

• 冲突时的差异显示误解
  有时候Git在处理冲突时，生成的冲突标记（<<<<<<</=======/>>>>>>>）看起来像是包含了前置变更，但其实是因为当前分支缺少必要的前置修改，导致Git无法精准计算目标提交的差异，只能把更大范围的代码差异展示出来，让你手动解决。

简单的排查与解决建议 #

1. 先查看目标提交的依赖链：执行git log --oneline --graph <目标提交哈希> ^master，看看这个提交之前有哪些在master上不存在的变更。
2. 如果确实有前置依赖，按顺序cherry-pick这些必要的前置提交，再处理目标提交；或者用git rebase --onto master staging~N staging（N是你要保留的提交数量）把staging上的相关提交移到master基础上，再切分支使用。
3. 如果是误选了合并提交，可以加上-m 1参数（比如git cherry-pick -m 1 <合并提交哈希>），指定以staging分支为父分支来应用合并提交的变更。

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