你说得完全正确！在已经推送到公共远程分支（比如staging这种多人协作的分支）的场景下，使用git revert确实是远优于git reset的规范做法——git reset会直接改写分支历史，导致其他协作开发者的本地仓库与远程仓库出现历史分歧，引发不必要的冲突；而git revert是通过新增一个反向提交来抵消目标提交的所有改动，全程不会破坏现有分支历史，对其他开发者非常友好。

接下来我们拆解你的步骤，同时修正一些细节问题：

你的步骤分析与修正 #

• 步骤1：创建cleaning分支
  其实不需要基于落后的master分支创建，直接从远程staging分支拉取本地分支会更高效，命令可以简化为：

  git checkout -b cleaning origin/staging
  

  这样一步就能创建一个与远程staging完全同步的本地cleaning分支，省去后续拉取的步骤。

• 步骤2：拉取远程staging到cleaning
  如果是按上面的方式创建的分支，这一步可以跳过；如果已经从master创建了cleaning，执行以下命令同步：

  git checkout cleaning
  git pull origin staging
  

• 步骤3：执行git revert
  这里你提到的“最后一个正常提交的哈希值”是错误的——你需要撤销的是那个合并提交本身，所以要使用合并提交的哈希值。另外，合并提交有两个父分支，revert时必须指定-m参数来告诉Git以哪个父分支为基准进行撤销（通常-m 1代表合并前的staging分支，也就是我们想要恢复到的状态）。命令格式如下：

  # 先通过git log找到合并提交的哈希（开头几位即可）
  git log --oneline
  # 执行revert，替换成你的合并提交哈希
  git revert -m 1 <合并提交哈希>
  

  执行后Git会自动打开编辑器让你填写revert提交的说明，保存退出即可完成反向提交。

• 步骤4：验证分支状态
  执行完revert后，cleaning分支的内容会和错误推送前的远程staging分支完全一致，但此时git status不会显示“与staging同步”——因为你新增了一个revert提交，本地cleaning分支会比远程staging领先1个提交，状态提示应该是：Your branch is ahead of 'origin/staging' by 1 commit.。如果显示同步，说明你没有成功生成revert提交，需要检查之前的操作。

• 步骤5：推送到远程staging分支
  确认本地cleaning分支的状态正确后，直接执行推送命令即可：

  git push origin cleaning:staging
  

  这条命令的意思是把本地cleaning分支的内容推送到远程的staging分支。如果之前已经将cleaning分支设置为跟踪远程staging（比如用git branch -u origin/staging），也可以直接执行git push。

额外注意事项 #

• 如果在你操作期间，有其他开发者向远程staging提交了内容，推送前记得先拉取最新代码（git pull origin staging），解决可能出现的冲突后再推送。
• 后续如果需要恢复被revert的合并提交，不能直接再次合并，需要用git revert <之前的revert提交哈希>来撤销这次revert操作。

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