---

title: 团队协作：多人开发的正确姿势
category: Git
tags: [Git, 版本控制, GitHub]

专栏介绍：本专栏专为刚入门的开发者打造的Git入门指南，从版本控制概念到团队协作实战，通过6篇文章带你掌握Git核心技能。
学习路径：版本控制基础 → 本地操作 → 远程协作 → 分支管理 → 团队协作 → 开源贡献

作者：带娃的IT创业者
简介：专注AI与自动化工具开发，致力于降低技术学习门槛

摘要

本文讲解团队协作的最佳实践，通过模拟多人开发场景，演示如何使用Pull Request进行Code Review和处理冲突。阅读本文后，你将学会：

• 团队协作的标准流程
• • 创建和审核Pull Request
• • 处理多人协作中的冲突

---

开篇故事：混乱的协作

小明和小红一起开发一个项目，他们的协作方式是这样的：

传统方式：

1. 小明发邮件给小红：“我改了main.py”
2. 2. 小红：“收到，我也改了，怎么办？”
3. 3. 小明：“你先发给我，我合并一下”
4. 4. 小红：“合并出错了…”
5. 5. 小明：“那我们重新开始…”
      结果：效率低下、容易出错、无法追溯

Git协作方式：
6. 小明创建分支开发功能A
7. 2. 小红创建分支开发功能B
8. 3. 分别提交Pull Request
9. 4. Code Review后合并
10.5. 自动处理冲突

结果：高效、清晰、可追溯

---

团队协作的标准流程

Git Flow工作流详解

完整流程：

1. 克隆项目
2.    ↓
3. 2. 创建功能分支
4.    ↓
5. 3. 开发并提交
6.    ↓
7. 4. 推送到远程
8.    ↓
9. 5. 创建Pull Request
10.   ↓
11. 6. Code Review
12.    ↓
13. 7. 合并到主分支
14.    ↓
15. 8. 删除功能分支
16. ```
---

## 实战案例：模拟2人协作

### 准备工作

假设GitHub上已有一个项目：`https://github.com/team/calculator`

**小明（开发者A）**：

```bash
# 克隆项目
git clone git@github.com:team/calculator.git
cd calculator

# 创建功能分支
git checkout -b feature/add-function

小红（开发者B）：

# 克隆项目
git clone git@github.com:team/calculator.git
cd calculator

# 创建功能分支
git checkout -b feature/multiply-function

步骤1：各自开发

小明开发加法功能：

# calculator.py
def add(a, b):
    return a + b
    ```
```bash
git add calculator.py
git commit -m "feat: 添加加法功能"
git push -u origin feature/add-function

小红开发乘法功能：

# calculator.py
def multiply(a, b):
    return a * b
    ```
```bash
git add calculator.py
git commit -m "feat: 添加乘法功能"
git push -u origin feature/multiply-function

步骤2：创建Pull Request

在GitHub网站：

1. 打开仓库页面
2. 2. 点击"Compare & pull request"
3. 3. 填写PR信息：
4. • 标题：feat: 添加加法功能
5. • 描述：

6.  ```markdown
   

7.  ## 功能说明
   

8.  添加两个数字的加法运算
   

10. ## 测试
    

11.  - [x] 已通过单元测试
    

12.  - [x] 手动测试通过
    

14.  ## 关联Issue
    

15.  Closes #1
    

16.  ```
    

17. 4. 点击"Create pull request"

步骤3：Code Review

团队成员在PR页面进行审核：

审核清单：

• 代码风格符合规范
• - [ ] 逻辑正确
• - [ ] 有单元测试
• - [ ] 无明显bug
  评论示例：

建议：这里可以添加参数类型检查

```python
def add(a: int, b: int) -> int:
    return a + b
    ```
    ```
**审核结果**：
- **Approve**：批准合并
- - **Request Changes**：要求修改
- - **Comment**：仅评论
### 步骤4：修改PR（如果需要）

```bash
# 小明根据审核意见修改
git checkout feature/add-function

# 修改代码...
git add .
git commit -m "refactor: 添加类型提示"
git push

# 自动更新PR（无需重新创建）

步骤5：合并PR

审核通过后：

1. 点击"Merge pull request"
2. 2. 选择合并方式：
3. • Merge commit：保留所有commit
4. • Squash and merge：压缩为单个commit
5. • Rebase and merge：线性历史
6. 3. 确认合并

步骤6：同步主分支

其他开发者同步最新代码：

# 切换到main分支
git checkout main

# 拉取最新代码
git pull origin main

# 删除本地功能分支
git branch -d feature/add-function

---

处理多人冲突

场景：两人修改同一文件

情况1：小明的PR先合并

main: A --- B --- C (小明的提交)

小红尝试合并时会冲突：

# 小红同步main
git checkout main
git pull origin main

# 切换到功能分支
git checkout feature/multiply-function

# 变基到最新的main
git rebase main

如果有冲突：

<<<<<<< HEAD
def add(a, b):
    return a + b  # 小明的代码
    =======
    def multiply(a, b):
        return a * b  # 小红的代码
        >>>>>>> feature/multiply-function
        ```
**解决冲突**：

```python
# 保留两份代码
def add(a, b):
    return a + b
def multiply(a, b):
    return a * b
    ```
```bash
git add calculator.py
git rebase --continue
git push -f origin feature/multiply-function

注意：-f强制推送，因为rebase改写了历史

情况2：GitHub提示冲突

如果PR页面显示"This branch has conflicts that must be resolved"：

方式1：网页解决

1. 点击"Resolve conflicts"
2. 2. 编辑冲突文件
3. 3. 点击"Mark as resolved"
4. 4. 提交
      方式2：本地解决（推荐）

git fetch origin
git checkout feature/multiply-function
git merge origin/main

# 解决冲突...
git add .
git commit -m "merge: 解决冲突"
git push

---

Code Review最佳实践

作为PR提交者

PR描述模板：

## 功能说明
简要描述这个PR做了什么

## 改动内容
- 添加了XXX功能
- - 修复了XXX bug
- - 重构了XXX代码
## 测试
- [ ] 单元测试通过
- [ ] - [ ] 手动测试通过
- [ ] - [ ] 性能测试通过（如适用）
## 截图
（如果有UI改动，附上截图）

## 关联Issue
Closes #123

等待审核时：

• 耐心等待，不要催促
• • 及时回复评论
• • 虚心接受建议

作为Code Reviewer

审核标准：

1. 功能正确性
3. ❌ 这个逻辑有问题，当x=0时会除零
5. 代码风格
7. 💡 建议：使用snake_case命名，符合PEP8规范
9. 性能优化
11. ⚡ 这里可以用列表推导式，更高效：
12. result = [x*2 for x in data]
14. 可维护性
16. 📝 这个函数太长了，建议拆分为多个小函数

评论语气：

• ✅ “建议…”、“可以考虑…”
• • ❌ “这里错了”、“这样不行”

---

分支保护规则

设置分支保护

在GitHub仓库Settings中：

1. Branches → Add rule
2. 2. Branch name pattern: main
3. 3. 勾选：
4. • Require pull request reviews before merging
5. • Require status checks to pass before merging
6. • Require linear history
     效果：

• 不能直接push到main
• • 必须通过PR合并
• • PR需要审核通过
• • 必须通过CI测试

---

常见误区

误区1：直接在main分支开发

问题：多人同时修改main，容易冲突

解决：使用功能分支

# 每个功能一个分支
git checkout -b feature/user-login
git checkout -b feature/user-logout

误区2：冲突时不看代码直接覆盖

问题：可能丢失重要修改

解决：仔细对比冲突代码

# 使用diff工具
git mergetool

# 或手动查看
git diff main feature/xxx

误区3：不写PR描述就提交

问题：审核者不知道改了什么

解决：使用PR模板

## 功能说明
## 测试
## 关联Issue

---

进阶技巧

1. 使用GitHub Projects管理任务

To Do → In Progress → Done
  ↓         ↓         ↓
    Issue   分支开发   合并
    ```
### 2. 自动化CI/CD

创建`.github/workflows/test.yml`：

```yaml
name: Tests

on: [push, pull_request]

jobs:
  test:
      runs-on: ubuntu-latest
          steps:
                - uses: actions/checkout@v2
                -       - name: Run tests
                -         run: |
                -           pip install pytest
                -           pytest tests/
                - ```
**效果**：每次PR自动运行测试

### 3. 使用Draft PR

开发中想提前展示：

```bash
# 创建Draft PR
# 在PR页面选择"Create draft pull request"

用途：

• 提前讨论方案
• • 寻求帮助
• • 展示进度

---

总结

核心要点回顾

1. 团队协作流程
2. • 创建功能分支
3. • 提交Pull Request
4. • Code Review
5. • 合并分支
6. 冲突处理
7. • 及时同步主分支
8. • 理解冲突原因
9. • 手动解决冲突
10. Code Review
11. • 认真填写PR描述
12. • 虚心接受建议
13. • 及时回复评论

实战检查清单

• 参与一次团队协作
• - [ ] 创建Pull Request
• - [ ] 进行Code Review
• - [ ] 处理一次合并冲突
• - [ ] 设置分支保护规则

下篇预告

下一篇《开源贡献：Fork与Pull Request的艺术》将带你：

• 参与开源项目
• • Fork工作流程
• • 提交第一个PR
    敬请期待！

---

如果本文对你有帮助，欢迎点赞收藏！ 👍
有问题欢迎评论区留言！ 💬