git revert 还有这个坑?

最近也是终于开启了代码编写之旅,我只能默默地说一句,写代码的感受,简直不能再爽!java

不过也因为 git 的分支管理蛋疼懵逼好久,因此必须记录以及和你们分享一下本次坑爹的旅行。git

写在前面

每一个公司相比都有本身的 git 分支管理规范,在项目组中开发人员较多的时候,这个就显得尤其重要。因此咱们必须得掌握 git 的分支管理。基本套路就是有一个主线,而后在迭代周期內,每一个开发人员拉取本身的分支,待开发完毕后你们再 merge 回主线,发布版本。vim

 
流程图

具体的 git 代码分支管理看这个好了:https://nvie.com/posts/a-successful-git-branching-model/服务器

怎么回事?

到底怎么就被 git 版本回滚给坑了呢?不急,待我慢慢道来。post

在咕咚的项目组中,在一个新的需求评审完毕,进入开发状态时,你们会基于 develop 分支拉取本身的分支,命名为 feature/XXX,而后各自在本身的分支上进行开发。指针

因为你们开发业务上的不一样,因此在需求开发完毕,整合代码的时候,通常都不会出现冲突的状况,即便出现,那也应该是比较容易解决的。日志

可在最近的一次 merge 中出现了一个比较奇怪的问题。code

如图所示:orm

 
1.png

我当前所在的分支是 feature8.29.0_nanchen,该分支已经 merge 了 release8.28.0 分支上的最新代码,本地没有任何提交。如今因为一些缘由,我须要把另一位同事开发的 feature8.28_buyGifts 分支代码合并到个人分支上。进行开发。开发

意外地出现了不少的冲突。

 
2.png

咱们使用 git status 看看到底发生了什么。

 
3.png

 

从截图中能够看出,git 认为咱们当前的分支 delete 了很多文件,而这些文件是在 feature8.28_buyGifts 分支上存在的。

咱们 vim 查看文件状况。这里就选取第一个 MarketItemsInfo.java 作截图。

 
4.png

咱们查看其余冲突文件之后,发现所有是和 Presents 这个类相关的冲突,而这些文件其实是开发 feature8.28_buyGifts 分支的小伙伴开发的,主分支不可能作干预,这里让人什么疑惑。

为了验证本身的猜测,咱们查看一下 MarketItemsInfo.java 的提交历史。

 
5.png

正如咱们所想,确实在 7 个月内,都没有人动过这个文件。

因此一个 7 个月都没有人动过的文件,怎么就会 merge 的时候出现了这个使人费解的冲突呢?

查看一下当前分支全部的日志。

 
6.png

彷佛发现了一点异常。这位小伙伴曾经往 release8.28.0 进行了 merge 操做,此后被告知未提测不能 merge 到主线的时候,他又对 release8.28.0 分支作了 revert 操做。因此可能所以让 git 认为 release8.28.0 上有了这样的文件修改,由于操做后面被 revert,因此用 git lg <fileName> 的时候,也看不到最近对文件的改动记录。

我如今只能说多是这个缘由,若是你们有高见的还望留言指导。

若是是这样,那么咱们只要在这次 revert 操做以前进行 merge feature8.28_buyGifts 分支代码的话,应该是不会出问题的。

为了验证,咱们从新创建一个分支,而后 reset 到 revert 操做以前,再进行 merge,查看是否还会出现这样的状况。

 
7.png

明显没有出现任务冲突。

咱们再试试,在 revert 后进行 merge 操做。

 
8.png

如咱们所想,当咱们 reset 到 revert 提交的时候,再进行 merge 直接发生了这个冲突。

这样的话,必定意义上,已经印证了咱们的想法。git 确实把这个文件当作修改了。

怎么处理?

遇到了这样的问题,直观上,确定是将冲突的改动,所有以这位小伙伴的代码为准,由于主线上的代码,已经确认是没有人动过这几个文件的。

最不济的方法,可能就是直接舍弃掉这个小伙伴的操做,而后强行把他后面写的代码,从新写一遍了(由于他后面的代码量不多)。

为何会出现这个 revert 操做?

说到底仍是这次 revert 惹的祸。

我询问该小伙伴后,得知,他是在 release8.28.0 主分支上 merge 了本身的代码,而且 push 到服务器后,被告知未提测的代码不能 merge 到主分支后,但愿遗弃 push 到服务器上的这个 merge 操做,因此才采用 revert 命令的。

正确的操做?

我写这个正确的操做题目,是真的不敢写的。不过仍是斗胆写了一下。若是我想遗弃本身 push 到服务器上的提交的话,我必定会选择 reset 后再进行 push 操做的。

  1. 首先使用 git reset —hard <版本号> 让 HEAD 指针指向 merge 前的 commit ID。(注意,这是直接放弃以后全部的提交,采用 --hard,这里由于是没有别人提交别的代码)
  2. 再使用 git push origin <分支名> —force 命令强行把提交 push 到服务器便可。

写在最后

实际上,我本身对 git 的操做也有些模棱两可,不过仍是但愿能用本次教训给你们简单作下交流吧。

相关文章
相关标签/搜索