协作模型

不同的团队和项目有不同的协作模式。理解各种协作模型，选择适合团队的方式，是高效协作的前提。

Fork + PR 模型（开源项目）

Fork + Pull Request 是开源项目的标准协作模式，也是 GitHub 最推广的工作流。

工作流程

原始仓库（upstream）
    ↓ fork
你的 Fork（origin）
    ↓ clone
本地仓库
    ↓ 开发、提交
你的 Fork（origin）
    ↓ Pull Request
原始仓库（upstream）

具体步骤

1. Fork 仓库

在 GitHub 上点击 Fork 按钮，将原始仓库复制到你的账户下。

2. 克隆你的 Fork

git clone git@github.com:your-username/repo.git
cd repo

# 添加 upstream（原始仓库）
git remote add upstream git@github.com:original-owner/repo.git

# 验证
git remote -v
# origin    git@github.com:your-username/repo.git (fetch)
# origin    git@github.com:your-username/repo.git (push)
# upstream  git@github.com:original-owner/repo.git (fetch)
# upstream  git@github.com:original-owner/repo.git (push)

3. 同步上游最新代码

git fetch upstream
git switch main
git merge upstream/main
# 或
git rebase upstream/main

4. 创建功能分支并开发

git switch -c feature/fix-issue-123

# 开发...
git add .
git commit -m "fix: 修复 #123 中描述的问题"

# 推送到自己的 Fork
git push -u origin feature/fix-issue-123

5. 创建 Pull Request

在 GitHub 上从 your-username:feature/fix-issue-123 向 original-owner:main 创建 PR。

PR 描述应包含：

• 解决的问题（关联 Issue：Closes #123）
• 改动内容概述
• 测试说明
• 截图（如有 UI 改动）

6. 响应 Code Review

# 根据 review 意见修改
git add .
git commit -m "fix: 根据 review 修改 xxx"
git push  # 自动更新 PR

7. PR 被合并后清理

# 同步上游
git switch main
git pull upstream main
git push origin main

# 删除功能分支
git branch -d feature/fix-issue-123
git push origin --delete feature/fix-issue-123

共享仓库模型（团队项目）

团队成员都有直接推送权限，通过分支保护规则和 PR/MR 流程确保代码质量。

权限设置

在 GitHub/GitLab 中设置：

• main/develop 等主要分支设为保护分支
• 禁止直接推送到保护分支
• 要求 PR 必须经过至少 1 人 review
• 要求 CI 检查通过

工作流程

# 克隆共享仓库（有写权限）
git clone git@github.com:team/repo.git

# 创建功能分支
git switch -c feature/user-profile

# 开发完成后推送
git push -u origin feature/user-profile

# 在 GitHub/GitLab 创建 PR/MR → Code Review → 合并

vs Fork 模型对比

对比项	Fork 模型	共享仓库模型
适用场景	开源项目	团队内部项目
权限管理	严格，外部贡献者无写权限	团队成员有写权限
工作复杂度	较高（需要同步 upstream）	较低
安全性	高（主仓库受保护）	依赖分支保护规则

同步 Fork 与上游仓库

保持 Fork 与上游同步是开源贡献中的常规操作：

# 方法1：通过命令行同步
git fetch upstream
git switch main
git merge upstream/main   # 或 rebase
git push origin main

# 方法2：通过 GitHub 界面
# 在你的 Fork 页面点击 "Sync fork" 按钮（GitHub 2022+ 功能）

同步过程中遇到分叉

如果你在 main 上有本地提交（不推荐），需要处理分叉：

git fetch upstream
git switch main
git rebase upstream/main  # 将你的提交移到上游最新提交之后
git push --force-with-lease origin main

最佳实践： 永远不要直接在 Fork 的 main 分支上提交，始终使用功能分支。这样同步上游就是简单的 merge 或 fast-forward。

Code Review 流程

Code Review 是保证代码质量的重要机制。

提交者的责任

PR 描述模板：

## 改动内容
- 添加了 xxx 功能
- 修复了 #123 的 bug

## 改动原因
解释为什么需要这个改动

## 测试说明
- [ ] 单元测试通过
- [ ] 集成测试通过
- [ ] 手动测试：测试步骤...

## 截图（如有 UI 改动）

Closes #123

提交 PR 前的自查清单：

# 1. 确保基于最新代码
git fetch origin
git rebase origin/main

# 2. 运行测试
npm test

# 3. 检查代码风格
npm run lint

# 4. 查看自己的改动
git diff origin/main..HEAD

# 5. 整理提交历史（如有必要）
git rebase -i origin/main

Review 者的责任

Review 要点：

• 代码逻辑是否正确
• 是否有安全漏洞
• 性能是否有影响
• 是否遵循团队代码规范
• 测试覆盖是否充分
• 错误处理是否完善

Review 反馈类型：

• Approve：代码可以合并
• Request changes：有必须修改的问题
• Comment：建议或疑问，不阻止合并

处理 Review 意见

# Review 要求修改后，在同一分支上继续提交
git add .
git commit -m "fix: 根据 review 修改变量命名"

# 或者用 fixup（之后用 autosquash 整理）
git commit --fixup <原提交 SHA-1>

# 推送后 PR 自动更新
git push

沟通技巧：

• 对不理解的 review 意见，提问而不是直接照做
• 如果不同意某个建议，友好地解释原因
• Review 者和提交者都是为了产品更好，保持尊重

GitHub 协作特性

相关的 Issue 引用

在提交信息或 PR 描述中：
Fixes #123       → PR 合并后自动关闭 Issue
Closes #123      → 同上
Resolves #123    → 同上
Related to #456  → 只是关联，不自动关闭

Draft PR

# 创建草稿 PR（表示工作还未完成，寻求早期反馈）
# 在 GitHub 上创建 PR 时选择 "Create draft pull request"

Code Review 的评论规范

前缀：
nit: 小问题，可改可不改（nitpick）
q: 问题/疑问
blocker: 必须修改，阻止合并
suggestion: 建议，非强制

总结

模型	适用场景	复杂度	控制粒度
Fork + PR	开源项目	高	高
共享仓库 + PR	团队项目	中	中
直接推送	个人项目	低	低

无论哪种协作模型，Code Review 都是保证代码质量的关键环节。建立良好的 Review 文化，让每个 PR 都经过认真审查，是高质量工程团队的重要特征。