git中reset与revert的练法

对两者之间的区别,写的太罗嗦了,后来自己练练手,练得多了,才有了自己的感觉,reset好比是物理学中的“位移”那样的感官,提交到哪个点,位移就是开始到现在这个点的距离,超过这个点走的路程被隐藏了不显示。
revert呢?打个比方吧,一个人每天都有一个生活记录,形成镜像,每个镜像从时间角度看就是依次联系逐渐成长的过程,但是每个镜像也是独立存在的,从一个镜像里可以看到从出生到镜像现在的变化。
revert就是单独作用在某个镜像,这个镜像不变,但是作用之后,产生了一个新的镜像,只不过可能会产生冲突,冲突只是因为为了产生新镜像,违背了其他镜像的逻辑性,但是跟其他镜像的关系也是独立存在的,不会去改变其他镜像的,这个新的镜像是我的目的。具体下面来练练手吧。

reset

如果改项目出了什么乱七八糟的错误,想回到以前觉得还不错的版本里,这里出现了不同的用户需求了,只要reset了,HEAD肯定会变到当时版本了,这个是为了让远程库得到这个版本的需求的。同时,暂存区可以同步改变,也可以保持现状,这个看个人需求了。同时,原文件也会相应地变或者不变的。

git reset --hard HEAD~

这个就是最简单粗暴的急救命令了,比如一个人从小孩到最光彩的中年再到老年死去,这命令可以让这个人直接回到最光彩的中年,场景一模一样,可以再活一次,当然老年的所有痕迹也都不会存在了。

这是我提交的commit记录,用log命令得出的
git中reset与revert的练法_第1张图片
五次改动依次输入了1,2,3,4,5。

我想回到3那次改动后的场景,包括暂存区和原文件都穿越了
git中reset与revert的练法_第2张图片

git中reset与revert的练法_第3张图片

这里运行status命令说明文件和暂存区一致的,运行log命令,如图,记录也仅仅到了当前3的,没有了4,5。
git中reset与revert的练法_第4张图片

git reset --soft HEAD~

这个命令就有趣了,这里的暂存区和文件是不变的。仅仅是对远程库的表现回到从前版本,感觉好像大牛开发项目远超其他伙伴,不得不把低版本的表现出来配合进度。
我先用上一个命令回到5的提交状态。

然后输入soft命令,再进行如下操作
git中reset与revert的练法_第5张图片

提示暂存区与本地库不一致了,用
git reset HEAD

来撤消暂存区文件了。打开vim后是这个
git中reset与revert的练法_第6张图片

还是5的状态,没变的。

然后之前在5状态时,已经跟远程库push过去了,然后进行操作
git中reset与revert的练法_第7张图片

得到提示,本地库已经落后于远程端了,需要用pull。
由此说明这里只有HEAD变了,暂存区和原文件没变。

revert

特定取消某个版本的提交,其他版本不管,只针对面上的一个点,所以没有路程或者位移的感觉了,并且提交后会产生新的commit被记录,好比,所有的项目都做差不多了,就是两天前的一个小文件有问题,如果要用到上面的reset的话,这两天就白干了。

我再用reflog查询命令记录,回到5的状态,开始编辑3次,把1,2,3,按顺序删除。用log得commit界面
git中reset与revert的练法_第8张图片

我想把2留下来,就是想撤消shan2这个提交。
git中reset与revert的练法_第9张图片

报错了,什么意思呢?这里你撤消shanchu2的提交,但是下面的shan3没有变,所以起了冲突了,打开文件
git中reset与revert的练法_第10张图片

HEAD当前结果为54,shan2的结果为5432,这里因为冲突很小,手动修改不麻烦,直接手动编辑,删除不想要的,得到想要的542,保存退出,然后
git中reset与revert的练法_第11张图片

再vim打开
git中reset与revert的练法_第12张图片

就是想要的结果啦。
如果手动编辑很麻烦的话呢?另一种做法:报错之后,先强制结束revert,默认 不 生成新的commit,并按顺序回滚。先log一下,查看commit
git中reset与revert的练法_第13张图片

我这次要撤消shan3的提交,也就是543。
命令图如下
git中reset与revert的练法_第14张图片

其中obort是强制中断命令,--no-commit参数就是不提交的意思,最后
git revert --continue

会自动跳出编辑框,填写提交注释的。

大体简单到这里,还有一些,比如reset命令撤消暂存区文件,可以使提交的文件具有选择性等等吧,大家可以一起研究下。现在感觉reset最好适合本地库谨慎使用的,不可随意使用提交之后推到远程库,容易让其他人看你远程库的时候云里雾里,revert倒是很实用,虽然撤消了提交,但是历史记录还在,新生成的提交的逻辑,外人很容易明白的。

思考

对于revert的两个运行例子,想了想结果其实挺怪的,第一个结果无所谓,我手改的结果如何,都符合revert的定义。第二个例子是在第一个例子作为HEAD的前提下开始的,结果呢,好像跟这个HEAD没关系,结果是543而不是5432,所以我突然想到了其中的逻辑, 只要运行revert得到的commit更像是在大树主干上分出的相互独立的枝杈,这些枝杈在逻辑上直接跟撤销commit时的主干有关联,互相之间没有关联,仅仅是在log图表上有个时间上的先后结果罢了,而“顺序回滚”是借助log图表完成的,而到了目标commit那里,需要执行revert的行为遵循的则是log而不是主干。所以,如果想通过revert得到不仅撤消了commit之后的文件,还要使文件继续遵循下面的commit变化得出的更新结果,好像只能用手动修改的方法了,顺序回滚得到的结果跟运用reset得到的结果差不多,只是有了每次操作提交的历史记录这个优点罢了。

你可能感兴趣的:(git中reset与revert的练法)