记录一次git冲突解决过程
记录一次冲突解决
git代码合并,冲突解决
前言:
首先需要明确的是:
- 虽然测试环境到预生产环境是递进关系,但是仓库分支名Release3到master2却不是递进关系。
- 功能业务分支名一般都是feature开头,而冲突解决名一般都是conflict,或 hotfix等。
- feature分支单纯的就是开发新功能,conflict分支单纯的是为了解决冲突而临时创建。
文中字段说明:
- Release3:也简称R3,测试环境的分支名
- master2:简称m2,预生产环境的分支名
其他:
每个公司仓库架构不同,分支定义不同,请自行提取有用内容
故事背景:
某天小明基于master2
分支创建了一个新的分支fetureaA
,功能开发完成后,需要将其新开发的功能合到Release3
上给测试同学进行测试。
这时候麻烦来了,在请求合并到Release3
的时候出现了冲突提示,但是又不知道哪些文件,哪些代码行出现冲突。此时需要解决冲突,才能将自己新开发的功能发布到测试环境。
为了解决冲突,小明基于Release3
创建了新的分支conflictA
,
并将featureA
上的内容合并到conflictA
中(冲突在本地的vscode
即可看到具体的地方)
提交了conflictA
,并将其合入到Release3
中(一定不会有冲突,因为是基于R3创建的),该临时分支
最后测试通过后,将featureA
分支合入到master2
,完成该需求的开发周期
(没错,我就是小明)
具体步骤
新需求来了,基于m2创建新分支featureA
假设当前处于m2 分支下,并一定是最新代码,可执行
git pull
更新
git checkout -b featureA
持续开发新功能中…
10 days later
要上测试环境了,请求合并到R3,兴高采烈的创建了一个MR,发现存在冲突
于是基于R3,创建新分支conflictA
假设当前处于R3 分支下,并一定是最新代码,可执行
git pull
更新切换分支:
git checkout Release3
git checkout -b conflictA
将featureA上所有的东西合入到conflictA中,
在vscode的终端中执行
此时一定会存在冲突
合入命令
假设当前分支处于conflictA,
git merge fetureA
vscode显示如下
此时可以在编辑器中删除不需要的部分,留下需要的部分,这个过程就是解决冲突的过程。
也可以使用在此处右键,对单个文件的所有冲突部分做批量操作
tips: 慎重使用,前提是你一定知道这个文件内容所保留的内容和你预期是一致的。
解决完所有冲突后,提交conflictA,并提交MR到R3,当成功合入R3后,原来feautureA得功能也就到R3中了
这个过程中
conflictA
充当了中间人的角色,将featureA
的新内容,给到了R3
此时,测试同学在测试环境中已经测到了新开发的功能,并通知你可以往预生产环境合入代码了
此时再将featureA的代码合入到m2中,至此该新需求开发完毕。
小结:
- 冲突解决的本质是:A合入到C时发生冲突,需要中间分支B(基于C创建)来提交A最新的内容。
git merge A
命令使用vscode
中左侧栏【合并更改】具体处理冲突内容(编辑器编辑文本一样)- 需正确理解R3,m2分支之间的关系
开放原子开发者工作坊旨在鼓励更多人参与开源活动,与志同道合的开发者们相互交流开发经验、分享开发心得、获取前沿技术趋势。工作坊有多种形式的开发者活动,如meetup、训练营等,主打技术交流,干货满满,真诚地邀请各位开发者共同参与!
更多推荐
所有评论(0)