场景一：已git add暂存但未提交
情况说明
文件已通过git add添加到暂存区，但尚未执行git commit
核心命令
# 撤销单个文件的暂存
git reset HEAD <file-name>
# 撤销所有文件的暂存
git reset HEAD .
# 等价的新式写法（Git 2.23+）
git restore --staged <file-name>
执行效果
- 将指定文件移出暂存区
- 保留工作区修改内容
- 文件状态恢复至
untracked或modified
场景二：已提交本地仓库但未推送
情况说明
已完成本地git commit，但尚未执行git push
核心命令
# 保留修改回退到前一版本（修改回到暂存区）
git reset --soft HEAD~1
# 撤销提交但保留修改在工作区（默认mixed模式）
git reset HEAD~1
# 彻底删除本次提交的所有修改
git reset --hard HEAD~1
模式对比表
| 模式 | 工作区 | 暂存区 | 适用场景 |
|---|---|---|---|
| –soft | 保留 | 保留 | 重新编辑提交信息或拆分提交 |
| –mixed | 保留 | 重置 | 默认模式，调整提交内容 |
| –hard | 清除 | 清除 | 彻底放弃本次提交的所有修改 |
场景三：已推送到远程分支
情况说明
提交已经通过git push推送到远程仓库
核心命令
# 生成反向提交（推荐方案）
git revert <commit-hash>
# 强制覆盖远程分支（慎用！）
git reset --hard HEAD~1
git push -f origin <branch-name>
方案对比表
| 方法 | 优势 | 风险 | 适用场景 |
|---|---|---|---|
| revert | 安全，不改变提交历史 | 产生额外提交记录 | 公共分支、团队协作 |
| reset | 保持提交线清晰 | 需要强制推送，破坏协作历史 | 私有分支、单人开发 |
场景四：合并远程master后需要回退
情况说明
已合并远程master分支，需要撤销合并操作
核心命令
# 查找合并提交的hash值
git log --merges
# 撤销合并提交（生成反向提交）
git revert -m 1 <merge-commit-hash>
# 强制回退方式（私有分支可用）
git reset --hard <pre-merge-commit-hash>
git push -f origin <branch-name>
参数说明
-m 1：指定保留的主线分支（通常1表示当前分支）- 需要解决可能出现的合并冲突
场景五：协同开发中的冲突回退
情况说明
在合并master后，存在：
- 其他人已合并代码到master
- 冲突文件已被他人修改
- 需要安全撤回错误提交
解决方案
# 1. 创建反向提交
git revert <your-bad-commit-hash>
# 2. 处理冲突文件（保留他人修改）
# 使用编辑器解决标记冲突后继续
git add <resolved-files>
git revert --continue
# 3. 推送修正后的提交
git push origin <branch-name>
操作原则
- 优先使用revert代替reset
- 保留他人修改的代码
- 通过新增提交修正错误
- 完成回退后通知团队成员
安全操作准则
- 操作前备份：使用
git stash或创建临时分支 - 历史追溯：善用
git reflog找回丢失提交 - 强制推送：-f参数只用于私有分支
- 团队协作：涉及公共分支的操作必须提前沟通
- 验证机制：回退后运行测试用例验证代码
可视化操作流程图
否
是
否
是
修改文件
已git add?
git restore
已commit?
git reset HEAD
已push?
扩展技巧
- 精准定位提交：
# 查找操作记录
git reflog show --date=iso
# 二分法定位错误提交
git bisect start
git bisect bad
git bisect good <commit-hash>
- 修改历史提交：
# 交互式变基（修改最近3次提交）
git rebase -i HEAD~3
- 补救错误reset：
# 通过reflog找回提交
git reflog
git checkout <lost-commit-hash>
掌握这些场景化操作方案，您将能够优雅地处理各种代码回退需求，在保证版本安全的前提下高效修正提交错误。