Git cherry-pick后合并分支出现异常行为的技术咨询

先给你吃颗定心丸：你遇到的情况完全是Git的正常逻辑，不是软件Bug。下面咱们拆解清楚背后的原因，以及怎么解决这个问题。

问题根源：Git靠「提交哈希」识别变更，而非内容 #

先梳理下你的提交历史线，这是理解问题的关键：

• master分支：1044abb（初始添加文件） → cce2ca5（从mybranch cherry-pick来的添加行提交） → f63dc50（删除那行文本的提交）
• mybranch分支：1044abb → 19afeba（最初添加那行文本的提交）

当你执行git merge mybranch时，Git的判断逻辑是这样的：

1. 找到两个分支的共同祖先：1044abb
2. 对比mybranch相对于祖先的变更：19afeba提交里新增了mutors kanoner och krut这一行
3. 对比master相对于祖先的变更：先在cce2ca5新增了同一行，又在f63dc50删除了它

这里的核心点是：Git把19afeba和cce2ca5当成两个完全独立的提交——哪怕它们的内容一模一样，但提交哈希不同，Git就会认为这是两个从未合并过的变更。所以合并时，Git会判定「mybranch里的添加行操作还没被应用到master」，于是自动把那行文本加了回来，覆盖了你之前的删除操作。

三种解决办法，按需选择 #

方法1：合并前给mybranch做变基（推荐） #

让mybranch的历史跟上master的脚步，Git会自动跳过已重复的变更：

# 切到mybranch
git checkout mybranch
# 把mybranch变基到最新的master上
git rebase master
# 切回master合并mybranch（此时会是快进合并，无冲突）
git checkout master
git merge mybranch

变基过程中，Git会发现19afeba的内容已经存在于master的cce2ca5里，会自动跳过这个提交，合并后就不会出现文本回滚的情况。

方法2：合并时强制保留master的版本 #

如果不想修改mybranch的历史，可以在合并时指定「优先采用master的内容」：

git merge mybranch -X ours

这个参数会让Git在处理所有潜在冲突时，直接用master的版本覆盖，你的删除操作就能保留。不过要注意：如果mybranch还有其他需要合并的变更，这个参数会一并覆盖，所以适合确认只有这一处冲突的场景。

方法3：在mybranch里反向提交抵消旧变更 #

如果你确定19afeba的内容已经通过cherry-pick应用到master了，可以在mybranch里创建一个反向提交来抵消它：

git checkout mybranch
# 反向抵消19afeba的提交
git revert 19afeba
# 再合并到master
git checkout master
git merge mybranch

这样mybranch的反向提交会和master的删除操作对应，合并后内容就会保持一致。

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