Git团队协作：让代码审查成为日常

Git团队协作：让代码审查成为日常

前两期我们掌握了Git的基础操作和分支管理。但Git的真正威力在于协作——让一群人同时开发，而不会互相踩脚。

这一期，我们来聊聊团队协作的最佳实践。

Fork vs Clone

Clone：直接克隆仓库，有写权限

git clone git@github.com:myteam/project.git

适用于团队成员，对仓库有直接写权限。

Fork：在你的账号下创建仓库副本

  1. 在GitHub/GitLab页面点击Fork
  2. 克隆你fork的仓库 
    git clone git@github.com:yourname/project.git

    适用于开源贡献者，对原仓库没有写权限。

Pull Request工作流

Pull Request（PR）是GitHub的叫法，GitLab叫Merge Request（MR）。本质相同：请求把你的分支合并到目标分支。

流程

graph TB
    A[从main创建feature分支] --> B[开发并提交]
    B --> C[推送到远程]
    C --> D[在GitHub创建PR]
    D --> E[代码审查]
    E --> F{通过?}
    F -->|是| G[合并PR]
    F -->|否| H[修改代码]
    H --> B
    G --> I[删除feature分支]

实战示例

# 1. 确保main是最新的
git checkout main
git pull origin main

# 2. 创建功能分支
git checkout -b feature/add-dark-mode

# 3. 开发...
git add .
git commit -m "feat: 添加暗黑模式支持"

# 4. 推送到远程
git push -u origin feature/add-dark-mode

# 5. 去GitHub/GitLab页面创建PR

创建PR时，填写：

  • 标题：简洁描述改动（如"feat: 添加暗黑模式支持"）
  • 描述：详细说明改了什么、为什么改、怎么测试
  • 审查者：指定审查代码的人
  • 标签：如enhancement、bug、documentation

好的PR长什么样？

标题格式（约定式提交）：

  • feat:：新功能
  • fix:：bug修复
  • docs:：文档更新
  • refactor:：重构
  • test:：测试
  • chore:：杂务（依赖更新、配置等）

描述模板：

## 改动描述
添加了暗黑模式支持，用户可以在设置中切换主题。

## 改动原因
用户反馈夜间使用时太刺眼，需要暗黑模式。

## 如何测试
1. 登录系统
2. 进入设置页面
3. 点击"切换主题"
4. 验证页面颜色变化

## 截图
![暗黑模式效果](screenshot.png)

## 相关Issue
Closes #123

一个PR只做一件事：

  • 不要把多个不相关的改动塞进一个PR
  • 小PR更容易审查，更快合并
  • 理想大小：200-400行代码

代码审查

代码审查（Code Review）是团队协作的核心。它不仅能发现bug，还能传播知识、统一风格。

审查者看什么？

  1. 正确性：代码是否实现了需求？
  2. 可读性：变量名、函数名是否清晰？逻辑是否易懂？
  3. 性能：有没有明显的性能问题？
  4. 安全：有没有SQL注入、XSS等安全隐患？
  5. 测试：有没有足够的测试覆盖？
  6. 风格：是否符合团队的编码规范？

审查评论类型

必须修改（Blocking）：

🛑 这里有个bug，变量未定义就会使用

建议修改（Non-blocking）：

💡 建议：这里用Array.filter会更简洁

提问：

❓ 为什么要用递归？迭代是不是更合适？

称赞：

👍 这个抽象做得很好！

作为被审查者

  1. 不要抵触批评：审查的是代码，不是你这个人
  2. 解释而非辩解：解释为什么这样写，而不是为错误找借口
  3. 及时响应：不要让PR挂着一周不动
  4. 自己先审查一遍：push前自己diff一下，避免低级错误
# 提交前自查
git diff main...HEAD  # 查看当前分支的所有改动

解决PR冲突

PR期间main可能有了新提交，导致你的PR冲突：

# 方法1：merge
git checkout feature/add-dark-mode
git fetch origin
git merge origin/main
# 解决冲突...
git push

# 方法2：rebase（推荐，保持线性历史）
git checkout feature/add-dark-mode
git fetch origin
git rebase origin/main
# 解决冲突...
git push --force-with-lease  # 注意：需要force push

注意：--force-with-lease比--force更安全，它会在远程有新提交时拒绝push。

Code Owner

大项目可以配置CODEOWNERS文件，自动指定审查者：

# .github/CODEOWNERS

# 前端代码由前端组审查
/frontend/ @myteam/frontend

# API代码由后端组审查
/api/ @myteam/backend

# 安全相关由安全组审查
**/auth* @myteam/security

保护分支

防止直接push到main分支，强制走PR流程：

GitHub设置：

  1. Settings → Branches → Add rule
  2. Branch name pattern: main
  3. 勾选：
    • Require a pull request before merging
    • Require approvals（需要几个人审批）
    • Require status checks to pass before merging（CI必须通过）

这样，任何人（包括管理员）都不能直接push到main，必须通过PR。

CI/CD集成

PR可以触发自动测试，只有测试通过才能合并：

# .github/workflows/test.yml
name: Test

on:
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - run: npm test
      - run: npm run lint

这样每次PR都会自动跑测试，测试失败就无法合并。

多人协作常见问题

问题1：Push被拒绝

! [rejected] main -> main (non-fast-forward)

原因：远程有新提交，你本地没有。

解决：

git pull --rebase origin main
git push origin main

问题2：别人的分支怎么更新？

# 获取所有远程分支
git fetch --all

# 查看同事的分支
git branch -r

# 基于同事的分支创建本地分支
git checkout -b feature-xxx origin/feature-xxx

问题3：如何同步Fork？

# 1. 添加上游仓库
git remote add upstream git@github.com:original-owner/project.git

# 2. 获取上游更新
git fetch upstream

# 3. 合并到本地main
git checkout main
git merge upstream/main

# 4. 推送到你的fork
git push origin main

问题4：不小心push了敏感信息！

# 立即删除敏感文件
git rm --cached config/secrets.yml
git commit -m "chore: 移除敏感文件"
git push

# 历史中还有！需要彻底清除
# 使用BFG Repo-Cleaner（推荐）
bfg --delete-files secrets.yml
git push --force

# 或用git filter-branch（慢）
git filter-branch --force --index-filter \
  'git rm --cached --ignore-unmatch config/secrets.yml' \
  --prune-empty --tag-name-filter cat -- --all
git push --force

重要：改写历史后，所有协作者需要重新clone仓库！

协作规范

Git提交规范

使用约定式提交（Conventional Commits）：

(): 

<footer>

示例：

feat(auth): 添加OAuth2.0登录支持

- 支持Google登录
- 支持GitHub登录
- 添加登录状态持久化

Closes #456

好处：

  • 自动生成changelog
  • 自动决定版本号（feat是minor，fix是patch）
  • 清晰的历史记录

提交信息模板

配置提交模板：

git config commit.template ~/.gitmessage

~/.gitmessage内容：

# :  (50 chars)
# |- - - - - - - - - - - - - - - - - - - - - ->|

#  (72 chars)
# |- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ->|

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

分支保护策略

graph LR
    A[feature分支] -->|PR| B[develop分支]
    C[bugfix分支] -->|PR| B
    B -->|PR| D[release分支]
    D -->|测试通过| E[main分支]
    F[hotfix分支] -->|PR| E
    E -->|backport| B

小结

你现在掌握了团队协作的核心技能：

  • Fork vs Clone的使用场景
  • Pull Request完整流程
  • 代码审查的最佳实践
  • 解决PR冲突
  • 配置分支保护和CI/CD
  • 多人协作常见问题解决

下一期，我们将进入高级主题——Git钩子和自动化。你会学到如何在commit/push时自动检查代码、运行测试、部署应用。

练习任务：

  1. 在GitHub创建一个测试仓库，尝试完整的PR流程
  2. 邀请朋友审查你的PR，练习代码审查对话
  3. 配置一个简单的GitHub Actions，自动运行测试
  4. 尝试在PR中制造冲突并解决

下期预告：《Git高级：钩子与自动化》—— pre-commit怎么配置？如何自动部署？Husky和lint-staged怎么用？

Views: 1

其他关联文章:

  1. Git钩子与自动化：让代码质量自动守护
  2. Git入门指南：从零开始掌握版本控制
  3. Vue3生态实战：Router、Pinia与完整项目
  4. Git分支管理：在平行宇宙中优雅开发

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

内容大纲

← Index