GitLab Merge request 合并分支时的冲突解决方案

原作者:softgoto

转载自: GitLab Merge request 合并分支时的冲突解决方案 | 个人小站

目录

环境介绍

创建合并请求

合并遇冲突

本地处理冲突

方式一:在本地将 develop 合并到 main,处理冲突后推送到远程的 main,GitLab 中的 Merge Request 自动完成合并

方式二:在本地将 main 合并到 develop,处理冲突后推送到远程的 develop,在 GitLab 中手动点击 Merge

两种方式的区别

自己合并的分支的方法


我们在开发新功能时,一般会从主线切出来一个 feature 分支,代码写完提交到远程分支之后,会在 GitLab 上发起 Merge Request,走完 Code Review 之后合并到主线。但多人协同开发的过程中可能会遇到代码冲突的问题,这里介绍一下在 Merge Request 过程中遇到冲突怎么解决。

环境介绍

主线分支:main

开发分支:develop

目标是将 develop 分支的内容合并到 main 分支

创建合并请求

首先在 GitLab 上创建合并请求,填好标题和描述信息,需要注意 Merge options: Delete source branch when merge request is accepted. 默认是勾选的,这里的意思是合并通过后会删除分支,根据需求选择就可以了

合并遇冲突

发起 Merge Request 之后,GitLab 会自动检测是否存在冲突,如果遇到冲突 Merge 按钮会变灰提示合并遇到冲突

本地处理冲突

在本地项目目录中打开 Git Bash 终端,查看本地分支

$ git branch -a

如果发现本地的分支数量和远程的分支数量不一致则需要获取远程更新,这里只会下载到本地,不会有合并动作(git fetch + git merge = git pull)

$ git fetch

确保本地有 main 和 develop 两个分支的代码,并且都是最新的

# 如果本地没有,从远程拉取并且在本地创建对应的分支
# git checkout -b <本地分支名> <远程分支名>
$ git checkout -b develop origin/develop

# 本地分支切换
$ git checkout develop

# 更新代码
# git pull <远程主机名> <远程分支名>:<本地分支名>
$ git pull origin develop:develop

这里有两种方式处理方式

方式一:在本地将 develop 合并到 main,处理冲突后推送到远程的 main,GitLab 中的 Merge Request 自动完成合并
# 本地切到main分支
$ git checkout main

# 将develop合并到main(--no-ff 禁止快进式合并)
$ git merge --no-ff develop

# 处理冲突文件(IDE中完成)

# 查看变动的文件
$ git status

# 保存并提交
$ git add .
$ git commit -m "解决了冲突"

# 推送到远程
$ git push origin main

注意:如果 main 分支是受保护的分支,并且开发人员的账号没有 merge 的权限,就只能用下面的方案了

方式二:在本地将 main 合并到 develop,处理冲突后推送到远程的 develop,在 GitLab 中手动点击 Merge
# 本地切到develop分支
$ git checkout develop

# 将main合并到develop(--no-ff 禁止快进式合并)
$ git merge --no-ff main

# 处理冲突文件(IDE中完成)

# 查看变动的文件
$ git status

# 保存并提交
$ git add .
$ git commit -m "解决了冲突"

# 推送到远程
$ git push origin develop

解决完冲突推送到远程的 develop 分支后,回到 GitLab 的 Merge Request 中会发现原来不能点的 Merge 按钮变绿了,手动点击 Merge 按钮整个合并过程就结束了。

两种方式的区别

方式一有限制条件,并且一般情况下 main 分支是受保护的分支,只有特定的账号才有权限,如果任何开发人员都有权限将代码 Merge 到 main 分支,那就是失去了使用 GitLab Merge Request 的意义。

自己合并的分支的方法

自己用着舒服哈哈,如果有不对,轻喷。

>当前有3个版本分支,测试环境:test,灰度环境:gray,正式环境:master

版本分支对应的代码版本永远是test≥gray≥master

>若干个开发分支:dev(可能同时有很多个人在开发不同的需求,或者修bug)

1.如果我开发完成了需求,我会首先把test 分支合并到自己的dev,同时处理冲突,因为此时可能会有其他同学的新代码。冲突处理完成后合并到test,此时dev=test

2.物理呼叫测试,“亲切交流”

3.有问题,修改dev分支,重复1

4.测试通过将test分支合并到gray,只要没人玩骚操作,此后的所有步骤不可能有冲突的

5.灰度环境也没问题,复制一份master分支为“master_旧版本号”,把gray合并到master

6.收工,摸鱼

  • 9
    点赞
  • 35
    收藏
    觉得还不错? 一键收藏
  • 5
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 5
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值