[Git] 重置回滚完全解读
一.前言
可能很多使用Git的人都很少会使用回滚操作, 因为不理解原理, 通常的操作是手动的进行代码还原, 这无疑增加了代码出错的风险, 而网上的教程不是直接给你扔一个命令行就是一大堆截图没有注释的操作, 你根本不知道哪一步是什么意思, 作为可能是地球上最牛逼的内容寻址文件系统, 下面我就来讲一下Git的回滚操作, 跟着我们的镜头一起来看吧.
二.正文
在这之前为了要模拟真实的场景, 我这里先做了一份提交记录, 很简单
在我们写代码的过程中分为这几种状态: 未提交, 已提交, 提交并推送, 那么下面就针对这3种状态分别给出解决方案
1.未提交 - 回退单文件
这个非常的简单
比如我们增加了555
这时sourceTree中会有对应的记录
我们只需要选择丢弃文件就可以了
注意这里的丢弃文件可不是删除文件, 很多人认为这是删除文件, 所以根本没有使用过
然后会询问是否丢弃所有的更改, 选择是后, 你所做的所有改动都会还原成上一次提交的时候
2.未提交 - 回退整个项目
在未提交前要把整个项目完全重置到某一次或上一次提交的状态只有一个办法, 这个我在视频里也讲过, 就是重置到此次提交, 选择强行合并
强行合并的意思是丢弃所有的改动, 也就是会变成与提交完789一模一样的状态, 那就是没有写555的状态
到这里未提交前两种状态的回退讲完了
好的下面开始走流程, 例子还是提交了555
3.提交后 - 回退单文件
我们可以把提交的状态变成提交前的状态并保持本地的代码不动, 再进行单个文件的丢弃操作, 你可能不理解, 下面上图
提交后我们的状态是
这个状态傻子都知道, 你是无法丢弃单文件的, 因为已经提交了
所以我们需要把待推送的状态还原成没提交时的状态, 注意是状态
这次我们就需要选择混合合并重置索引了, 重置完索引后, 改变的是提交状态, 而不是内容, 所以我们会看到这样的场景
我们的提交记录回来了, 这时你会有个疑问, 我们的提交记录回来了, 为什么推送按钮上还有未推送内容, 这其实是sourceTree的Bug, 我们点击推送后不会出现任何效果 - -, 当然蓝色的1会消失, 但是并没有推送
之后我们就可以用单文件丢弃的方式来丢弃改动了
这时我们看看我们的提交记录
可以说是非常的干净, 正常, 整洁
4.提交后 - 回退整个项目
- 方法1 回滚 - 回退整个项目
好的接着上面的说, 提交后回退整个项目, 我们就可以使用回滚了
状态还是这样
这次我们要选择555, 然后选择回滚
回滚后我们先来看一下效果
有没有发现不同之处, 回滚后竟然有一个提交记录, 记录的意思是你回到了555之前的状态, 也就是789, 所以回滚相当于帮你写了一个回滚的提交日志, 并提交了改动
很多人到这里就会问了, 要还原成上次提交的状态, 不是应该选择789记录回滚吗, 这里是非常容易出错的, 如果你是789记录回滚, 那么你的状态就会变成456提交后的状态, 并且会冲突
因为修改落到了同一行上, 所以回滚需谨慎
到了这里我们就能看出回滚和重置提交的区别了
1.回滚要回到提交前的状态是要选择当前记录进行回滚, 而重置到记录则是要选择想要去的记录上进行还原
2.回滚会留下提交日志, 而重置记录是不会有日志
3.回滚可以做到完全丢弃上一次的提交内容并更新记录到最新索引上, 而重置记录是做不到完全舍弃覆盖的
第三条是重中之重
第三条是重中之重
第三条是重中之重
那这个冲突要如何解决呢? 聪明的你肯定会知道, 我这里就提个醒
1.你可以把这个改动丢弃 - -
2.你可以重置提交记录到你想要的地方
3.可以试试回滚回去
- 方法2 重置提交 - 回退整个项目
我不想墨迹这里了, 赶紧去强制合并去, 别忘了要选789
3.提交并推送后
提交并推送后, 与没推送前, 唯一的区别就是代码已经到了云端, 所以你做完回退操作想要让云端生效的话, 需要再推送一次, 注意我们无论是回退还是重置都是针对于本地的, 在你没有提交前都不会破坏项目, 所以在做危险的操作前对项目进行备份是非常有必要的
