Git中回滚已合并变更A及重新应用提交B、C的方法咨询

嘿，我来帮你理清楚这两个Git操作问题～

Q1: 回滚变更A的正确操作，以及手动覆盖方式是否合理？ #

首先说正确的回滚姿势：既然变更A已经合并到Develop，而且之后还有B、C两个提交，绝对不能用reset回退（会直接丢掉B、C的提交记录），最优解是用git revert命令。

你只需要先找到变更A对应的提交哈希（可以用git log --oneline快速查看），然后在Develop分支上执行：

git revert <A的提交哈希>

这个命令会生成一个全新的提交，把A带来的所有变更完整撤销，同时100%保留B、C的内容。最关键的是，Git的提交历史是完整可追溯的，后续任何人看记录都能清晰看到「什么时候合并了A，什么时候因为问题回滚了A」，排查问题非常方便。

再来说你尝试的手动覆盖方式：这种操作非常不合理，甚至可以说是踩了Git的大坑。手动复制旧版本内容覆盖最新版本，相当于直接跳过了Git的版本追踪机制，会带来几个严重问题：

• 丢失了回滚操作的历史记录，以后没人知道你为什么把文件改回了旧版本；
• 如果B、C的提交里有依赖A的变更（比如用到了A新增的变量、函数），手动覆盖很容易把这些依赖内容也删掉，导致代码报错；
• 这种「暴力修改」会让Git的提交历史和文件状态脱节，后续做对比、合并、回溯都会出问题——这其实也是Q2问题的根源。

Q2: 重新应用B、C的可行办法，以及和Q1操作的关联 #

你的问题确实是Q1的手动操作导致的：你把Develop的文件强行拉回了A合并前的状态，但Git的提交历史里依然保留着B、C的合并记录，现在文件状态和历史基准线完全不匹配，自然无法正常生成差异对比。

不过别慌，还是有办法重新应用B、C的，推荐两种方案：

方案一：用cherry-pick单独提取B、C的变更 #

1. 先用git log --oneline找到B、C两个提交的哈希值；
2. 在当前的Develop分支上执行：

git cherry-pick <B的提交哈希> <C的提交哈希>

这个命令会把B、C两个提交的变更单独提取出来，应用到当前的Develop分支上。过程中大概率会出现冲突（因为当前文件是A之前的状态，而B、C是基于A之后的代码写的），你只需要手动解决冲突，然后依次执行git add .和git cherry-pick --continue完成操作即可。

方案二：重新从原feature分支合并 #

如果B、C对应的feature分支还存在的话，直接在当前Develop分支上重新合并这两个分支：

git merge feature/B
git merge feature/C

同样会触发冲突，解决冲突后完成合并就行。这种方式的好处是能保留原分支的合并记录，比cherry-pick更贴合原本的分支管理流程。

总结一下：以后遇到需要回滚已合并的提交，优先用git revert，绝对不要手动覆盖文件——Git的版本追踪就是用来干这个事的，别自己绕远路踩坑～

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