首页 › Git › 团队协作（在新窗口打开） › Pull Request 流程

什么是 Pull Request

Pull Request（PR / Merge Request）是代码审查和协作的核心机制——开发者向仓库提交变更请求，其他成员审查通过后合并。

标准 PR 流程

详细步骤

# 1. 创建功能分支
git switch -c feature/my-feature

# 2. 开发、提交
git add .
git commit -m "feat: add new feature"

# 3. 推送（首次需设置上游）
git push -u origin feature/my-feature

# 4. 在 GitHub/GitLab 上创建 PR

Fork 工作流

当你没有仓库写入权限时，使用 Fork 工作流：

# 1. 在 GitHub 上 Fork 上游仓库

# 2. Clone 自己的 Fork
git clone git@github.com:your-username/repo.git
cd repo

# 3. 添加上游仓库地址
git remote add upstream https://github.com/original-owner/repo.git

# 4. 保持与上游同步
git checkout main
git pull upstream main
git push origin main

# 5. 基于最新 main 创建功能分支
git switch -c feature/xxx

# 6. 开发 → 提交 → 推送到自己的 Fork
git push origin feature/xxx

# 7. 在 GitHub 上对上游仓库创建 PR

Code Review

审查者的关注点：

维度	检查项
逻辑	实现是否正确？边界条件是否覆盖？
安全	是否有注入风险？敏感信息未泄露？
性能	是否有效率的改进？有没有 N+1 查询？
可读性	命名是否清晰？是否过于复杂？
测试	是否包含测试？覆盖率是否足够？
一致	风格是否符合作业规范？

处理 Review 意见

# 1. 根据意见修改代码
# 2. 提交新的变更
git add .
git commit -m "fix: address review comments"

# 3. 推送到同一分支（PR 自动更新）
git push origin feature/my-feature

合并选项

GitHub 提供三种合并方式：

方式	效果	适用场景
Create a merge commit	保留完整分支历史	团队偏好保留分支
Squash and merge	将 PR 所有提交压缩为一个	功能开发有多个 commit
Rebase and merge	线性历史，不保留分支	追求整洁历史

Commit Message 规范

推荐 Angular 约定格式：

<type>(<scope>): <subject>

<body>

type	含义
feat	新功能
fix	Bug 修复
docs	文档
style	格式（不影响代码运行）
refactor	重构
test	测试
chore	构建/工具

# 好的 commit message
git commit -m "feat(auth): add OAuth2 login"
git commit -m "fix(api): handle null response on timeout"
git commit -m "docs(readme): update installation instructions"

小结

• PR 是团队协作的核心，流程：创建分支 → 开发 → 推送 → PR → Review → 合并。
• Fork 工作流适合没有写入权限时的外协开发。
• Code Review 关注逻辑、安全、性能、可读性、测试。
• 推送到同一分支会自动更新 PR，无需新建。
• Commit Message 推荐 Angular 规范（feat: / fix: / docs:）。

上一节：reflog 与 clean 下一节：Git Flow 与 GitHub Flow

贡献者: 布欧-Lewyon