我是跟野兽差不了多少1. 先理清需求：删除commit前必须搞清楚的三个问题
我在处理GitLab仓库时，遇到过很多次“想删掉某个commit”的需求。最常见的是这几种：误把密钥提交上去了、某个功能改动被证明是错的想从历史里移除、一条旧提交里带了一个不该进仓库的大文件，或者纯粹是本地提交历史太乱想整理一番。
先说结论：在GitLab的repo里删除特定commit，不是单靠一个命令就能搞定的，它取决于三件事——这个commit是本地还是远程、你希望它彻底消失还是只撤销效果、以及你所在的仓库是单人维护还是多人协作。这三点没想清楚就动手，很容易把仓库历史搞坏，严重的还会让同事的本地代码整个乱掉。
1.1 你面对的提交到底在哪儿
删除commit的第一步是判断这条提交的“位置”。如果它只存在于你本地，那你随便怎么折腾都行，不会影响任何人；但如果它已经通过git push推到了GitLab的远程分支上，操作就复杂了。因为远程仓库里的commit是共享的，改了它，等于改变所有同事看到的版本历史。
判断方法很简单：在本地执行git log看最近的提交记录，然后对比GitLab网页上的分支提交记录。如果两边的commit哈希一致，说明已经推送过了；如果本地有而远程没有，那就是还没推送。还有另一种情况：commit在远程，但不在你本地，比如同事推上去的。这种情况下你本地根本没有这个commit，也就谈不上“删除本地”，实际上要做的是改写远程分支的引用。
1.2 彻底抹除历史，还是只撤销效果
这是最容易混淆的地方。很多人说“删除commit”，其实内心想的是“让代码恢复到这个commit之前的状态”。但“删除该commit”和“撤销该commit”在Git里是两种完全不同的操作。
删除，意味着从提交历史上抹掉这一条记录，后续的commit会重新排列，哈希全部改变。撤销，则是追加一条新的反向提交，把代码改回去，但原来的commit依然留在历史里。两者对应的命令分别是git reset（或git rebase -i）和git revert。
| 对比维度 | git reset/rebase删除 | git revert撤销 |
|---|---|---|
| 历史记录 | 原commit彻底消失 | 原commit保留，新增一条反向commit |
| commit哈希 | 后续commit哈希全部改变 | 原有哈希不变 |
| 是否需要force push | 需要，否则远程拒绝 | 不需要，normal push即可 |
| 对协作者影响 | 大，同事旧分支会错乱 | 小，同事可以正常pull |
| 适合场景 | 密钥泄露、错误提交未合入主干 | 已合入共享分支、不想破坏历史 |
我在实际工作中，除非是极特殊的情况，否则凡是对外共享的分支，一律优先用revert。这不仅仅是为了省事，更是为了照顾整个团队的开发节奏。后面我会专门讲为什么。
1.3 单分支协作还是多仓库协同
还有一个容易被忽略的维度：你操作的仓库是单仓库还是像Android那样用repo工具管理的多仓库工程。前者逻辑简单，改一个仓库就够了；后者牵扯到manifests、多个project的同步逻辑，操作方式差异很大。另外，GitLab里还有分支保护机制，如果目标分支是protected branch，直接force push是被禁止的，需要先去设置里临时放开权限，这一块很多新手会卡住。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 本地未推送场景：三个最常用的“后悔药”
如果commit只在本地，那操作空间非常大，几乎不用担心副作用。这个场景下我常用的手段有三种，按需求不同选择其中一种。
2.1 git reset：软重置与硬重置怎么选
git reset是把当前分支的HEAD指针挪到指定commit位置，后面不要的commit直接甩掉。它有三种模式：--soft、--mixed、--hard。很多新手上来就--hard，结果把改动全弄丢了，然后在群里哀嚎。
我的建议是：不确定工作区还有没有需要保留的改动时，先跑git status。然后这样选：
- 只是想让HEAD回到旧位置，代码改动还想留着继续改，用
git reset --soft <commit>，暂存区会保留所有旧commit的改动。 - 想让改动从暂存区掉到工作区，重新整理后再次提交，用
git reset --mixed <commit>，这是默认模式。 - 确定旧commit之后的所有改动都不需要了，一心想让代码彻底回到某个历史节点，才用
git reset --hard <commit>。
举个实际场景。我本地基于main分支开了个功能分