运维工程师技术教程之Pull Requests（PR）

Pull Requests（PR）# Pull Requests（PR）：Git协作开发的核心流程详解

Pull Request（简称PR，部分平台如GitLab也叫Merge Request，MR）是分布式版本控制系统（Git）协作开发中最核心的功能之一，本质是开发者向代码仓库提交代码合并请求，让维护者审核、讨论、修改后将分支代码合并到主分支（如master/main），是团队协作、代码评审、版本管控的关键环节。

结合你之前操作的Gitee/GitHub/GitLab等平台场景，以下从核心概念、完整流程、实操步骤、注意事项四部分讲清PR的使用：

一、PR的核心价值

代码评审（Code Review）：提交PR后，团队成员可逐行审核代码，提出修改意见，避免bug直接合入主分支；
协作追溯：PR会记录所有讨论、修改、审核记录，便于后续追溯问题；
分支隔离：开发者在自己的功能分支开发，通过PR合入主分支，避免直接修改主分支导致代码混乱；
自动化集成：可联动CI/CD（如自动跑单元测试、代码扫描），确保合入代码符合质量要求。

二、PR的完整协作流程（以Gitee为例，GitHub/GitLab逻辑一致）

前提：基础分支准备

假设你是开发者，目标是向travelpro仓库的master分支提交功能代码：

克隆远程仓库到本地：

bash 复制代码

git clone https://gitee.com/xxx/travelpro.git
cd travelpro

基于主分支创建功能分支（避免直接修改master）：

bash 复制代码

git checkout master  # 先切回主分支并拉最新代码
git pull origin master
git checkout -b feature/xxx  # 创建并切换到功能分支（如feature/payment）

在功能分支开发代码（修改、新增文件），提交并推送到远程：

bash 复制代码

git add .
git commit -m "feat: 新增支付功能"
git push -u origin feature/xxx  # 推送到远程功能分支

步骤1：在平台端创建PR

登录Gitee，进入travelpro仓库；
点击顶部「拉取请求」→「新建拉取请求」；
选择「源分支」（你推送的feature/xxx）和「目标分支」（仓库的master）；
填写PR标题（如「新增支付功能」）和描述（说明修改内容、解决的问题），点击「创建」。

步骤2：代码评审与修改

仓库维护者收到PR通知后，会审核代码：
- 若有问题，会在PR下留言（如"支付逻辑需补充异常处理"）；
- 你根据意见在本地功能分支修改代码，重新提交并推送：
  bash 复制代码
```
git add .
git commit -m "fix: 补充支付异常处理"
git push origin feature/xxx  # 推送后PR会自动更新
```
审核通过后，维护者会点击「合并」→ 选择合并方式（如普通合并、变基合并）→ 确认合并。

步骤3：合并后清理（可选）

本地切回master分支，拉取合并后的最新代码：
bash 复制代码
```
git checkout master
git pull origin master
```
删除本地功能分支（若无需保留）：
bash 复制代码
```
git branch -d feature/xxx
```
删除远程功能分支（若团队约定清理）：
bash 复制代码
```
git push origin --delete feature/xxx
```

三、PR的关键注意事项

1. 合并前必做

确保功能分支与目标分支（master）无冲突：若平台提示冲突，先在本地合并master并解决冲突：

bash 复制代码

git checkout feature/xxx
git merge master  # 合并master代码
# 手动解决冲突文件（标记<<<<<<<的部分），然后提交
git add .
git commit -m "merge: 解决与master的冲突"
git push origin feature/xxx

确保CI/CD校验通过（如单元测试、代码规范扫描），未通过的PR不建议合并。

2. 不同平台的小差异

平台	PR入口	特殊点
Gitee	拉取请求 → 新建	支持"自动合并"（无冲突时）
GitHub	Pull requests → New	支持"Draft PR"（草稿，暂不审核）
GitLab	Merge requests → New	命名为MR，支持" squash合并"（压缩提交）

3. 规范建议

PR标题遵循约定式提交（如feat: xxx/fix: xxx/docs: xxx）；
单个PR聚焦一个功能/问题，避免超大PR（难审核）；
描述中关联需求/BUG编号（如"解决#123号BUG：支付金额计算错误"）。

四、常见问题解决

1. PR提示代码冲突

原因：目标分支（master）已被其他人修改，与你的功能分支代码冲突。

解决：按上文"合并前必做"的步骤，本地合并master并手动解决冲突后重新推送。

2. 提交PR后想撤回/修改标题

撤回PR：在平台PR页面点击「关闭」（未合并时）；
修改标题/描述：直接在PR页面编辑即可，无需重新创建。

3. 合并后发现BUG

紧急修复：创建hotfix分支（hotfix/payment-bug），修复后提交新PR合入master；
回滚合并：若BUG影响严重，在平台找到合并记录，执行「回滚提交」（Gitee/GitHub均支持）。

总结：PR是Git协作的核心，核心逻辑是"分支开发→提交审核→修改优化→合并主分支"，规范使用PR能大幅降低团队协作的代码风险，尤其适合多人维护的仓库（如你的travelpro项目）。如果需要针对Gitee平台的PR操作做截图式分步演示，或补充CI/CD联动PR的配置，都可以告诉我。