⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 juejin.cn/post/7365414174217355314 「奔跑的毛球」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注微信公众号：【芋道源码】有福利：

RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表

RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址

您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。

新的源码解析文章实时收到通知。每周更新一篇左右。

认真的源码交流微信群。

又是一遭悲惨的遭遇，git提交了一连串代码之后，发现提交错了。其实是把给老婆发的消息打到了comment里，然后还提交上去了。怎么办，这被看到岂不是要社死了。

一连串的研究之后，找到了几个解决方案。接下来我们一起搞搞这种错误提交的弥补方案。其中最离谱的是第三个方案。哈哈。

赛前准备

这里模拟一下这个操作，毕竟不能直接看我们的代码记录。我们新建一个项目，新建一个文件，起名001。

然后依次改为 002 003 004 005，每次都提交一次，在005的时候，执行异常提交。

最终我们得到一个005的文件

gitee上看是这样的

对于我们来说，现在是想删除这个异常提交，不仅删除代码，还想删除记录

也就是说，期待的是，文件变为004，而且这个提交记录删除掉。

方案1 交互式 rebase

首先我们尝试一下 git rebase -i HEAD~3，这样会取出最后的三条提交记录供我们编辑。

我们可以看到顶上有三条记录，这时候，我们删除这个异常的提交5

保存之后，会返回

git rebase -i HEAD~3
Successfully rebased and updated refs/heads/master.

这时候查看记录

异常提交已经没有了。

但是若是我们直接git push 会报错

告诉我们，我们当前的分支的版本是落后于远程分支的，不能提交。

这时候就需要git push --force这个命令，强制推送！！！

需要注意的是，强制推送会覆盖远程仓库中的历史记录，因此请确保你知道这个命令是个啥，并且有必要的话，需要通知团队其他成员协调好操作。

可以看到，git push --force 是可以成功的，而且再看gitee的记录

异常提交5已经不见了。并且本地的文件已经变为了004

其实在git rebase -i HEAD~3这个命令打开的交互框里是可以更改提交的顺序的，但是不能针对同一个文件的同一行，会冲突。

方案2 git reset

git reset 其实之前写文章讲过Git reset到底该如何使用，一文读懂系列[1] 这次我们就直接为达目的，直接使用。我们在上边的基础上，再提交一个异常提交5，使其恢复最初的情况。

然后gitee的情况：

这时候我们执行

git reset --hard HEAD~1

这个命令将删除最近的一个提交，包括提交所做的更改。请注意，这种方法可能会导致丢失未提交的更改，也就是说，本地写的没提交的代码就没了。所以请谨慎使用。

执行之后，我们可以看到异常提交5不见了

提交的时候也需要git push --force这个命令，强制推送！！！为啥每次都使用三个！！！呢，我只想告诉你，这个命令很恐怖，一定要慎之又慎。

这时候查看gitee记录

异常提交5没有了。

使用 git revert

还有小伙伴会说，为啥不用git revert呢，这不是git专门用来回滚代码的吗？

我们恢复异常提交005，再试试

我们执行 git revert f3d8db 并且 push

可以看到，文件是从005变为004了。但是从提交记录来看，不仅没有删除记录，还多了一条。其实，除非提交的注释特别社死，不然一般用的就是git revert，因为它不仅可以保存记录，还能确保版本是往前走的。

方案3 git filter-branch（谨慎使用）

查资料的时候，还看到一个这个命令，可以来一波骚的了。那既然提错了，把这锅甩给新人不就行了，哇咔咔咔咔咔。

git filter-branch --commit-filter '
    if git log --format="%B" -n 1 $GIT_COMMIT | grep -q "异常提交"; then 
         GIT_AUTHOR_NAME="new baby"; 
         GIT_COMMITTER_NAME="new baby"; 
         git commit-tree "$@"; 
     else 
         git commit-tree "$@"; 
     fi' -- --all

然后就是这样的

可以看到名字变了。当然邮箱也是可以改的。哇咔咔，这异常不就与我没关系了么。。。但是，极其不建议这么瞎折腾哈。

这个命令会根据条件重写整个历史。操作之前备份一下吧，别折腾坏了。而且一定先和其他的小伙伴商量一下，尤其是新人哈。

在此，就研究完毕了。正常来说使用第一种或者第二种方案都是可以的。不怕挨打的话，第三种方案也行。

git rebase 和 git reset 的区别

git rebase 命令用于将一个分支的提交移动到另一个分支上，或者重新应用一系列的提交。它的主要作用是改变提交的基础，即重新设置提交的起点。
git reset 命令用于修改当前分支的 HEAD 引用，或者用于撤销之前的提交操作。

也就是说git rebase 用于重新整理提交历史，而 git reset 用于调整当前分支的位置或撤销更改。关于这两个详细的使用，git reset已经写过了，有关git rebase的我会新开一篇文章，有关将一个分支的提交移动到另一个分支上这个操作虽不常用，但总有需要用到的时候。

Reference

[1]Git reset到底该如何使用: https://juejin.cn/post/7311681326712242239

芋道源码 —— 纯源码解析博客

Git提交错了，看我如何巧妙把锅甩给了新来的baby