梗概
虽然Git提供了修改历史commit的方法，但不推荐这种做法，应该尽可能保证所有提交都是正确的、完整的。
不推荐修改历史commit的原因
20%核心原因
Git的操作是基于历史commit的，更改一个历史commit可能会导致后面的commit都需要更改，即可能产生非常多冲突。
80%详细说明
技术风险
- 修改历史会改变commit的哈希值
- 可能导致分支历史不一致
- 团队协作中会造成混乱
- 需要强制推送，风险较高
协作风险
- 其他开发者基于旧commit的工作会受影响
- 可能导致代码丢失或重复冲突
推荐的替代方案
基本原则
- 应该尽可能保证所有提交都是正确的、完整的
- 未完成的更改就不要提交，可以暂存或者新开一个分支保存临时的提交
常见场景处理
正在做需求时来了紧急需求
推荐做法：
- 新建一个分支，暂时保存当前需求的更改为提交
- 切换去做另一个更紧急的需求
- 哪个需求先完成，就先提交哪个
- 其他暂存需求就rebase最新的代码，处理冲突
核心原则：谁后提交谁处理冲突
发现已推送的错误提交
- 已推送且被他人拉取 → 用
[[git的revert命令|git revert]]（安全） - 未推送或团队可协调 → 用
[[git的reset命令|git reset]]（需同步）
相关操作
- git rebase - 整理提交历史
- 压缩commit - 合并多个提交
- 撤销git操作 - 各种撤销场景