如何修正master分支历史中的错误提交且不破坏分支历史？

由于不能修改master的公共提交历史（避免团队协作混乱），且错误提交已在master提交栈深处，最稳妥且符合团队协作规范的方案是单独创建修复分支撤销错误提交中的不当修改，具体步骤如下：

步骤1：准备修复分支 #

• 切换到master并拉取最新代码：

  git checkout master && git pull origin master
  

• 创建专门用于修复的分支：

  git checkout -b fix/revert-unintended-changes
  

步骤2：定位并撤销错误修改 #

• 找到那个有问题的提交哈希值（可通过git log --oneline查看），假设为<BAD_COMMIT_HASH>
• 查看该提交的具体修改内容：

  git show <BAD_COMMIT_HASH>
  

• 根据修改内容选择性撤销不当部分：
  • 如果是单个文件的部分代码被错误修改：手动编辑文件恢复正确代码，然后用git add <file-path>暂存
  • 如果是整个文件被错误修改：恢复到该提交之前的版本：

    git checkout <BAD_COMMIT_HASH>~1 -- <file-path>
    

  • 也可以用git add -p交互式选择要暂存的恢复内容，精准控制撤销范围

步骤3：提交修复并合并到master #

• 提交修复，提交信息要明确说明撤销的内容：

  git commit -m "Revert unintended changes from commit <BAD_COMMIT_HASH>: 恢复[具体文件/代码块]到错误修改前的状态"
  

• 推送修复分支到远程，走团队的常规合并流程（比如创建PR、等待审核），确保所有团队成员知晓这次修复

步骤4：合并自己的开发分支到master #

• 切换到你的开发分支：

  git checkout your-dev-branch
  

• 拉取最新的master代码：

  git pull origin master
  

• 此时合并应该只会产生少量合理冲突，手动解决后提交，再走合并流程即可

备选方案：在自己的开发分支中直接处理冲突 #

如果不想单独创建修复分支，也可以在自己的开发分支rebase时直接处理：

• 拉取远程master的最新代码：

  git fetch origin
  

• 以远程master为基准rebase自己的分支：

  git rebase origin/master
  

• 遇到冲突时，针对被错误覆盖的代码部分，手动恢复自己的实现，同时保留错误提交中合理的修改
• 完成rebase后，推送分支（如果之前已推送过，需要用git push --force-with-lease，务必提前和团队沟通），再提交PR

关键注意事项 #

• 绝对禁止修改master的公共提交历史：交互式rebase修改历史会导致团队所有成员的本地仓库与远程不一致，引发大规模协作问题
• 尽早处理：拖得越久，master上的新提交越多，冲突范围会越大，修复成本越高
• 明确记录修复内容：提交信息和PR描述要清晰说明修复的是哪些错误修改，方便团队后续追溯

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