协作篇-Day23｜协作规范：分支工作流（主分支 / 功能分支），Pull Request

9 次阅读 · 2026-10-30 14:59

📖 知识点

1. 分支工作流（主分支 / 功能分支）

分支	角色	规则
`master`（主分支）	稳定可用版本	别直接改，只接收 "审查通过" 的合并
`功能分支`（如 feature - 会员）	开发新功能	从主分支开出，开发完再合并回去

master ─────────────────────── 稳定主线
        └─ feature-会员 ──开发──┘  ← 功能分支，做完合回主线

规范：开发在功能分支，合并到主分支前要审查。主分支永远保持 "能上线" 的稳定状态。

2. Pull Request（合并请求 / PR）是什么？

PR（Pull Request） 是把功能分支请求合并到主分支的一个 "申请 + 审查" 流程：你提交合并申请，同事 / 负责人审查代码，通过后才真正合并。

💡 生活比喻PR 像 "提交审批单"：你把新功能写成 "申请单"（PR），领导审一遍（code review），没问题签批（approve），才能合并进正式版本。防止烂代码直接进主线。

3. PR 的完整流程（团队协作标准动作）

① 开功能分支开发 → ② 提交并 push 到远程
→ ③ 在平台发起 Pull Request（请求合入主分支）
→ ④ 同事审查代码（Review）
→ ⑤ 审查通过 → ⑥ 合并到主分支

平台（GitHub/Gitee）上点 "New Pull Request" 发起，合并前有人把关。

4. 团队日常配合

git pull              # 开工先同步
git checkout -b feature-新功能   # 开功能分支
# ...开发、提交、push...
git push -u origin feature-新功能  # 推送，然后在平台发起PR

功能分支命名常带 feature- 前缀，一看就知道是干嘛的。

⚠️ 易错提醒
主分支（master）保持稳定，别直接改，只接收审查通过的合并
新功能开功能分支开发，命名如 feature-会员、feature-支付
合并前走 PR 审查，防止烂代码直接进主线

⚔️ 剧情 Kata 实战任务

任务需求：

确认当前在 master，先 git pull 同步
从主分支开出功能分支 feature-会员日
在功能分支开发、提交、push 到远程
模拟 "发起 PR"：说明你的分支已推上去，等待审查合并
汇总团队规范：主分支稳定 + 功能分支开发 + PR 审查

参考代码（在终端依次敲）

# 0. 进仓库，同步
cd ~/外卖App
git switch master
git pull

# 1. 开功能分支开发
git checkout -b feature-会员日
echo "def 会员日活动(): return '全场8折'" >> 外卖App.py
git add 外卖App.py
git commit -m "feat: 新增会员日活动"

# 2. 推送功能分支到远程
git push -u origin feature-会员日

# 3. 模拟"发起PR"：查看当前分支和要合入的主分支
git branch
git log --oneline
# （真实流程：到GitHub/Gitee点New Pull Request，请求把feature-会员日合入master）

运行示例：

user@linux:~/外卖App$ git push -u origin feature-会员日
To https://github.com/行者孙/外卖App.git
 * [new branch]      feature-会员日 -> feature-会员日

user@linux:~/外卖App$ git branch
* feature-会员日
  master

💡 完成动作示意：
git switch master + git pull → 开工先同步
git checkout -b feature-会员日 → 从主分支开功能分支
开发提交后 git push -u origin feature-会员日 → 推送到远程
git branch 看到在功能分支上 —— 接下来到平台发起 PR，请求把该分支合入 master，走审查流程

🧠 思考题

分支工作流里，master 主分支和功能分支各有什么规则？为什么主分支要保持 "稳定可用"？
Pull Request 的作用是什么？为什么说它是 "防止烂代码直接进主线的审查关"？