Gitee自动创建PR之——评审模式

一 创建PR的常规操作

  • 本地更新主干(一般为master分支),基于主干新建一个分支并(如Dev分支)切换;

  • 进行新的需求开发;

  • 将这个分支推送到远端;

  • 打开 Gitee ,进入创建 Pull Request 界面; 

  • 选定目标分支(及我们需要合并到主干分支的分支,一般即为我们的开发分支);

  • 填写 Title 以及 Description;

  • 点击提交 Pull Request。

二 更快的常见PR的方式— — 评审模式

现在 Gitee 可以设置保护分支为 「评审模式」,无此分支推送权限的用户,推送后都将自动创建(或者更新)一个 Pull Request。

评审模式的定义:

为了解决上文中创建 Pull Request 流程繁琐的问题,我们扩展了保护分支,将保护分支分为两种模式:

  • 标准模式:与原有保护分支逻辑一致,严格遵循推送和合并的权限,如无权限,推送将被拒绝。

  • 「评审模式」:与标准模式唯一不同的一点是,「如果用户没有推送权限,那么他的推送将会自动创建/更新一个 Pull Request」

设置保护分支:

 设置保护分支的审查模式:

 设置审查模式规则:

 在「仓库管理-保护分支设置」中,该仓库的管理员新增了一个保护分支规则 main,并且设置了它为评审模式以及禁止任何人推送,那么其他仓库成员往main分支推送代码,都会自动创建一个 Pull Request。

暂时研究至此,后续研究再来总结,待续。。。

### Gitee多人协作开发流程 #### 创建存储库与初始设置 为了启动一个多成员参与的项目,在Gitee上首先要创建一个新的存储库。这一步骤不仅限于建立一个代码存放的地方,还意味着搭建了一个团队共同工作的平台[^3]。 #### 分支管理策略 采用功能分支工作流(Feature Branch Workflow),即每位开发者基于主干分支(main/master)创建自己的特性分支来进行新特性的开发。这种做法有助于隔离不同功能的开发活动,减少相互干扰的可能性,同时也便于追踪各个功能的具体进展状况[^1]。 #### 推送更改至远程仓库 完成本地修改后,需将这些改动推送到个人在Gitee上的远端副本中。此操作可以通过命令行工具执行`git push origin <branch-name>`来实现;对于偏好图形界面的操作者来说,则可以选择像VSCode这样的集成开发环境所提供的可视化Git支持进行推送动作[^5]。 ```bash git add . git commit -m "描述本次提交的内容" git push origin branch_name ``` #### 发起合并请求(Pull Request) 一旦确认所负责的功能已达到可交付状态,便可以在Gitee平台上发起一个Pull Request(PR),正式提议将自己的变更合入到项目的主线之中。PR不仅是技术层面的一次更新尝试,更是一个沟通交流的机会——它允许其他队员审阅即将引入的变化,并给出反馈意见或建议改进之处[^4]。 #### 审核与合并 收到PR通知后的管理员或其他指定评审人会对其中涉及的变动进行全面评估,包括但不限于代码风格一致性、逻辑正确性等方面考量。如果一切顺利并通过必要的自动化测试验证,则批准该PR并将相应变更加入目标分支内。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值