原作者: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.收工,摸鱼