Git回滚需据提交状态选命令：未推送用rebase -i或reset，已推送且共享则必须用revert；revert生成反向提交、安全可逆，reset改写历史、禁用于公共分支。
连续多次提交合并与撤销不是“选一个命令就行”的事，得先分清：这些提交在本地还是已推送到远程？有没有被别人拉取或基于它继续开发？不同场景下，git rebase -i、git reset 和 git revert 的适用性、风险和操作逻辑完全不同。
用 git rebase -i 合并本地未推送的多次提交
这是最干净的整理方式，但仅限于你自己的、尚未 push 到远程的提交。一旦别人基于其中某次提交做了开发，强制重写历史会破坏协作基础。
-
git rebase -i HEAD~N（N 是你想合并的提交数，比如HEAD~3表示倒数第 4 次提交及之后的 3 次） - 编辑器中把要合并的提交前的
pick改成squash或s，注意只能 squash 到它前面那个pick提交上 - 保存退出后，Git 会打开另一个编辑器让你重写最终的 commit message；若中间有冲突，解决后
git add .再git rebase --continue - 如果改错了想放弃，直接
git rebase --abort，一切回到操作前
撤销已 push 的多次提交：别用 reset，用 git revert
只要提交已经 git push 到远程，且可能被他人拉取过，就绝对不能用 reset + push -f。这会强行改写公共历史，导致协作者 fetch 后出现分裂、重复提交甚至丢失工作。
- 撤销最近一次提交：
git revert HEAD - 撤销连续多次提交（如最近 3 次）：
git revert HEAD~2..HEAD（注意是两个点，不是三个） - 撤销某次合并提交（比如误合了 feature 分支）：
git revert -m 1 <merge-commit-hash>，-m 1表示保留主分支（第一个父提交）的变更，撤销被合并分支的改动 - 每个
revert都会生成一个新提交，不破坏原有历史，安全可逆
git reset --soft 和 --hard 的真实区别与误用高发点
很多人以为 --soft 就是“安全版 reset”，其实它只影响 HEAD 指针位置，暂存区内容照旧；而 --hard 会直接丢弃工作区所有未提交修改——这两者都不是“撤销合并”的通用解法，尤其对合并提交。
-
git reset --soft HEAD~1：只回退 HEAD，git status显示所有改动仍在暂存区，适合改完 commit message 后重新commit -
git reset --hard HEAD~1：彻底丢弃上一次提交 + 所有工作区更改，不可恢复（除非有 reflog） - 对合并提交（merge commit）执行
reset --hard，会连同它的两个父提交一起丢掉，极大概率破坏分支拓扑，慎用 - 如果只是想取消一次正在进行中的
git merge（还没 commit），应该用git merge --abort，而不是 reset
合并后才发现问题：如何精准撤销某次合并而不动其他
当主分支上已有多个合并（如 merge branch-a、merge branch-b、merge branch-c），只想撤掉 branch-b 的那次，关键在于识别它的合并提交 hash，并确认后续提交不依赖它的变更。
- 用
git log --oneline --graph --all找到目标合并提交，它通常带两个 parent，形如Merge branch 'branch-b' - 运行
git revert -m 1 <hash>，生成反向 patch 提交 - 如果 revert 后发现功能异常，说明后续提交实际依赖了
branch-b的代码，此时不能简单 revert，需人工评估是否要 cherry-pick 补丁或重构逻辑 - 切记：revert 合并提交后，该分支未来再合入时 Git 会认为“已处理过”，可能跳过部分变更，必要时需
git revert掉之前的 revert 提交来“解除屏蔽”
真正容易被忽略的是时间线污染问题：哪怕你用 rebase -i 把 5 次提交压成 1 次，只要这个新提交 hash 被推到远程，其他人再拉取时仍会看到原始的 5 条 reflog 记录——所以版本整理的核心从来不是“看起来多干净”，而是“是否破坏了他人的本地历史”。
