你遇到的情况其实很典型：当你用Revert撤销了之前的特性分支合并后，Git会把那个撤销操作作为一个新提交记录下来。这时候直接合并修复后的特性分支，Git会认为原特性分支的提交已经被处理过（虽然是被撤销了），所以只会合并你后来修复的部分。下面是两种安全的方法，不用重置生产分支就能把原特性代码+修复内容一起合并回去：

方法一：Revert 之前的Revert提交（最推荐） #

这是最简单直接的方式，相当于“撤销撤销操作”，把原特性分支的代码先恢复回来，再合并修复后的变更：

1. 先切换到生产分支并拉取最新代码：

   git checkout production
   git pull origin production
   

2. 找到你之前创建的Revert-Feature-Branch对应的提交哈希值（可以通过git log查看，或者在GitHub的提交历史里找到那个标注着“Revert 'Merge branch feature-branch'”的提交）
3. 执行Revert操作，恢复原特性分支的代码：

   git revert <revert-commit-hash>
   

   这时候Git会生成一个新提交，把之前被撤销的特性代码重新加回来。
4. 现在合并修复后的特性分支：

   git merge feature-branch
   

   这次合并会把你在特性分支里做的bug修复也同步到生产分支。
5. 最后推送到远程生产分支：

   git push origin production
   

这种方法的好处是完全保留了生产分支的历史记录，所有操作都是添加新提交，不会影响其他开发者的本地分支，非常适合生产环境。

方法二：Cherry-pick原特性分支的提交（适合多提交场景） #

如果你的特性分支包含多个独立的提交，而你想更精细地恢复这些代码，可以用cherry-pick：

1. 同样先拉取最新的生产分支：

   git checkout production
   git pull origin production
   

2. 找出原特性分支中所有被Revert的提交哈希值（可以通过git log feature-branch查看，或者从之前的Revert提交描述里找到被合并的特性分支提交范围）
3. 把这些提交逐个cherry-pick到生产分支：

   git cherry-pick <commit-hash-1> <commit-hash-2> ...
   

   如果遇到冲突，解决冲突后执行git cherry-pick --continue即可。
4. 合并修复后的特性分支：

   git merge feature-branch
   

5. 推送到远程：

   git push origin production
   

关键注意事项 #

• 不管用哪种方法，操作前一定要确保生产分支是最新的，避免合并冲突。
• 合并完成后，务必在测试环境验证功能正常，再推送到生产环境。
• 绝对不要在生产分支上执行git reset这类修改历史的操作，会导致其他开发者的本地分支与远程分支不一致，引发混乱。

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