一、问题场景:今天我在某功能分支上完成了一个小功能迭代,并且已经在本地commit了。当我准备向服务器push时,还是习惯性地执行git pull --rebase进行同步,以防止入库服务器失败。没想到悲剧就发生了,即git pull --rebase失败。
二、原因分析:
1、发现是自己坑了自己,原因是昨天将某条bugfix分支merge过来时,出现冲突并解决了,但是有同事又往这条功能分支提交了新功能并已经入库了。
2、遇到这种情况,我想到了两种解决方法:一是git pull --rebase;二是因为merge冲突比较少,就先reset该功能分支再pull到目前服务器上的最新提交,最后执行merge和解决冲突操作。
(1)我是先尝试了方案一,即执行git pull --rebase,结果发现这样做没用。重点来了,rebase失败了,因为没有执行rebase abort操作,导致了今天我再次执行git pull --rebase操作失败。
(2)没办法,最后是使用了方案二才解决了该问题并入库到服务器。
3、自己埋的坑就要自己来填,对于今天的这个问题,没遇到过只能走一步算一步,所以我就执行了rebase abort操作,没想到执行后已经回退到我昨天的merge提交。幸运的是,git reflog给我开了生路。
命令:git reflog
说明:该命令可以查看git历史操作记录,比如commit、reset操作的记录
三、总结:该命令在特定场景下还是非常实用的,当你执行了git reset回退了某次本地commit之后,因为该commit还没提交到服务器上,你又想恢复到该次commit,就可以使用该命令查看该commit id,然后再执行git reset commit id操作就可以了。
本文详细介绍了在Git操作中遇到拉取冲突时的应对策略,包括如何正确使用rebase和reset命令,以及如何利用gitreflog恢复误操作。通过实例分析,读者能够学习到在本地提交冲突后的有效解决方案,确保代码仓库的一致性和完整性。

1270

被折叠的 条评论
为什么被折叠?



