记一次GitLab(GitLab Community Edition 9.3.11)上合并冲突,解决后生成一条反过来的合并,并且覆盖了合并来源的代码

一般公司都会自己部署gitlab来管理git仓库,有时候就会上去提交合并请求.再一次申请合并请求是发现有冲突故去解决冲突,解决完点击确认合并,惊奇的发现会生成一条反向合并而且会用目标分支覆盖来源分支(代码回滚了),这个是的巨大的坑这里记录下,以免大家也入坑!

详细情况:

A(源分支)往B(目标分支)分支合并,发生冲突

解决完冲突确认合并

1.看B分支会有一条合并记录A->B的提交记录

2.看A分支会发现一条B->A的合并记录,并且覆盖所有未解决冲突的代码(代码回滚了)

操作图:

A(hank-test)->B(hank-test1)发起合并发生冲突提示解决冲突:

点击解决冲突按钮:

 这里使用来源分支A(hank-test)的代码解决冲突,解决完点击确认提交:

到合并页面刷新会发现合并请求已经可以合并了,但是仔细看下面生成了一条很诡异的提交记录,就是B(hank-test1)到A(hank-test)的反向合并记录:

到分支A(hank-test)上去看,你会发现有一条反向合并记录(合并请求还没点确认,只是确认提交了冲突的解决),你说蛋疼不!

这里总结原因应该是gitlab必须把你解决冲突的提交先合并到源分支,这样这次的合并请求才没有冲突,才可以继续合并,而不需要开新的分支合并

所以大家还是避免使用这个功能吧(在GitLab上解决合并冲突)