嗨，这个问题我之前碰到过好几次，核心原因是Git的合并追踪机制在起作用——你之前用git revert -m撤销合并时，Git已经把A分支的那些提交标记为「已经在B分支处理过」了，所以后续再拉取/合并时会直接跳过它们。下面给你两种靠谱的解决办法，你可以根据自己的场景选择：

方法一：撤销之前的合并撤销操作（推荐） #

这种方法能完整保留操作历史，让团队成员通过日志清晰看到整个过程：

• 先切换到B分支，确保本地是最新状态：

  git checkout B
  git pull origin B
  

• 用git log找到你之前执行git revert -m生成的那个撤销提交，一般它的提交信息会是类似Revert "Merge branch 'A' into B"的内容，复制它的哈希值。
• 对这个撤销提交执行revert，把之前的合并变更恢复回来：

  git revert <刚才复制的撤销提交哈希>
  

  这里不需要加-m参数，因为这只是一个普通提交，不是合并提交。
• 现在再合并A分支的变更就正常了：

  git merge A
  

  这时候Git会自动合并A分支后续的新提交，同时之前被撤销的变更也会重新生效。

方法二：用cherry-pick重新引入目标提交 #

如果觉得方法一的日志有点冗余，也可以直接把A分支里被撤销的那些原始提交重新应用到B分支：

• 切换到B分支：

  git checkout B
  

• 用git log A找到之前合并到B又被撤销的那些原始提交（注意要排除合并提交本身，只挑A分支上的单个提交），把它们的哈希值记下来。
• 逐个将这些提交cherry-pick到B分支：

  git cherry-pick <提交哈希1> <提交哈希2> ...
  

  如果遇到冲突，解决完冲突后执行git cherry-pick --continue即可。
• 最后合并A分支的最新提交：

  git merge A
  

小提醒 #

• 方法一的优势是历史清晰，适合需要保留完整操作轨迹的团队；
• 方法二更简洁，但会生成新的提交哈希，相当于重新执行了一遍那些变更，适合对历史整洁度要求更高的场景。

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