Gitee PR review过程中冲突解决

Gitee上合并代码需要先push到个人仓再发起Pull Request(PR)到公共仓,如果个人的PR review周期过长,而在此过程中有其他PR合入公共仓,此时产生冲突,造成个人的PR无法何入,此时需要解决冲突,PR才能继续合并。

假设本人需要合并的是patch1,他人在本人PR review期间何如的是patch2,两人都是基于patch0进行修改。

1、保存修改,然后reset到初始状态

git format-patch -k -1

mv 1.patch ../

git reset --hard 0

2、将远程仓库的目标分支拉取到处理分支

git pull https://gitee.com/src-openeuler/dpdk.git master

此时应该是顺利合并的,而patch 顺序变成0-2

3、合入patch1

git am ../1.patch

git apply --reject ../1.patch

导出冲突,解决冲突至目标修改后状态

4、合并

git add .

git am --continue

此时patch顺序变成0-2-1,且此1已修改

5、提交

git push -f

此时,在PR上可以看到自己的PR状态更新,可以合并

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
在软件开发PR(Pull Request)是指开发人员将自己的代码变更提交到源代码管理系统(如Git),并请求其他开发人员进行代码审查和合并的过程。在PR过程,constraint(约束)指的是对代码变更的限制或要求。这些约束可以包括以下内容: 1. 代码风格规范:通常,在团队会有一套统一的代码风格规范,例如使用特定的缩进风格、命名规范、注释要求等。在PR过程,开发人员需要遵守这些规范,以保持代码的一致性和易读性。 2. 单元测试要求:在进行代码变更时,可能需要编写对应的单元测试来验证代码的正确性。在PR过程,可能会要求开发人员编写相应的单元测试,并确保代码变更没有破坏现有的测试用例。 3. 依赖管理和版本控制:如果代码变更涉及到修改或添加新的依赖项,可能需要遵循团队的依赖管理和版本控制规范。这可能包括使用特定的依赖管理工具(如Maven、npm)和指定适当的依赖版本。 4. 安全性和性能要求:在进行代码变更时,可能需要考虑到系统的安全性和性能。开发人员可能需要遵循特定的安全编码实践,如避免常见的安全漏洞(如SQL注入、跨站脚本攻击等)。此外,还可能需要注意代码的性能,避免引入性能瓶颈或资源浪费。 5. 文档要求:在进行代码变更时,可能需要更新相关的文档,如README文件、API文档、用户手册等。开发人员可能需要确保相应的文档与代码变更保持一致,并提供足够的说明和示例。 这些约束可以根据具体的项目和团队而有所不同,开发人员在进行PR时应该仔细阅读相关的约束要求,并确保自己的代码变更符合这些要求。

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值