04 - 团队协作与 Code Review本章目标掌握团队协作开发的核心技能学会在 GitLab 上进行高质量的 Code Review。一、Pull Request / Merge Request 的本质PRGitHub 叫法/ MRGitLab 叫法不是请求合并代码而是一次技术评审的过程。开发者提交 MR │ ▼ CI/CD 自动跑测试 ← 必须通过 │ ▼ Code Review人工审核← 至少 1 人批准 │ ▼ 合并到目标分支 │ ▼ 自动部署如果有 CI/CD二、MR 的正确打开方式2.1 创建一个好的 MR# MR 标题和 commit message 一样要规范 feat(auth): implement user login with JWT # MR 描述模板 ## 改动说明 - 新增登录页面login.html - 实现 JWT 认证逻辑auth.service.js - 添加登录 API 接口/api/auth/login ## 关联 Issue - Closes #123 ## 测试说明 - 本地测试通过 - 添加了登录功能的单元测试 ## 截图如果是前端改动 [粘贴截图]2.2 MR 原则✅ 好的 MR - 一个 MR 只做一件事 - 代码量控制在 200-400 行以内 - 有清晰的描述和测试说明 - 关联了 Issue/Jira 编号 ❌ 不好的 MR - 把 5 个功能混在一个 MR 里 - 1000 行代码没有描述 - 没有关联任何 Issue2.3 GitLab MR 操作步骤1. 推送代码到你的分支 git push -u origin feature/user-login 2. 打开 GitLab进入项目 3. 点击 New Merge Request 4. 选择源分支和目标分支 5. 填写标题和描述 6. 指定审核人Reviewer 7. 点击 Create Merge Request三、Code Review 全流程3.1 作为 Reviewer审核别人的代码审核清单□ 功能完整性 - 代码是否实现了需求 - 边界条件是否处理 - 错误处理是否完善 □ 代码质量 - 命名是否清晰有意义 - 代码是否可读 - 是否有重复代码 - 函数是否过长 □ 安全性 - SQL 注入 - XSS 攻击 - 敏感信息是否硬编码 □ 性能 - 有没有明显的性能问题 - 数据库查询是否合理 □ 测试 - 是否有测试 - 测试覆盖是否足够 □ 规范 - 是否符合团队编码规范 - Commit message 是否规范3.2 如何给出好的 Review 评论# ❌ 不好的评论这代码有问题# ✅ 好的评论 这里有个潜在的空指针问题。当 user 为 null 时调用 user.getName()会抛异常。 建议 javaif(user!null){String nameuser.getName();//...}或者用 OptionalOptional.ofNullable(user).map(User::getName).ifPresent(name-{// ...});3.3 评论类型标签标签含义必须改吗nit/nits小问题建议但不强求否suggestion改进建议否issue/bug必须修复的问题是question需要解释的地方看情况四、解决 Merge 冲突团队协作最常见的痛点4.1 冲突产生原因main 分支 A — B — Cfeature 分支 D — E如果 C 和 E 修改了同一个文件的同一部分合并时就会冲突。4.2 解决冲突的标准流程# 方法一在本地解决 # 1. 保持你的分支最新gitcheckout feature/user-logingitfetch origingitrebase origin/main# 2. 如果有冲突Git 会暂停# CONFLICT (content): Merge conflict in src/login.js# Automatic rebase failed; fix up your branch and run git rebase again.# 3. 查看冲突文件gitstatus# both modified: src/login.js# 4. 编辑冲突文件# 文件中会有标记HEAD 你的代码别人的代码def5678# 5. 手动选择保留哪部分或合并两者# 6. 删除冲突标记 # 7. 标记冲突已解决gitaddsrc/login.js# 8. 继续 rebasegitrebase--continue# 9. 推送需要 force push因为历史被重写了gitpush --force-with-lease4.3 冲突解决技巧# 使用可视化工具解决冲突gitmergetool# 使用 VS Code 解决冲突推荐# VS Code 会高亮冲突点击 Accept Current / Accept Incoming / Accept Both# 放弃本次 rebase/mergegitrebase--abortgitmerge--abort4.4 减少冲突的最佳实践1. 频繁同步每天至少拉一次 main/develop 2. 小步提交MR 越小冲突概率越低 3. 及时合并MR 通过后尽快合并不要拖 4. 通信协调多人改同一文件时提前沟通五、Fork 工作流开源项目常见如果你在开源社区贡献代码通常没有直接 push 的权限需要 Fork。┌─────────────────────────────────────────────┐ │ 原始仓库upstream │ │ github.com/org/project │ └──────────────┬──────────────────────────────┘ │ ┌──────────┼──────────┐ │ │ │ ▼ ▼ ▼ Fork A Fork B Fork C 你的 别人的 别人的# 1. Fork 原始仓库到你的 GitHub# 2. 克隆你 Fork 的仓库gitclone gitgithub.com:your-name/project.gitcdproject# 3. 添加原始仓库为 upstreamgitremoteaddupstream gitgithub.com:org/project.git# 4. 查看远程仓库gitremote-v# origin gitgithub.com:your-name/project.git (fetch)# origin gitgithub.com:your-name/project.git (push)# upstream gitgithub.com:org/project.git (fetch)# upstream gitgithub.com:org/project.git (push)# 5. 同步 upstream 的最新代码gitfetch upstreamgitcheckout maingitmerge upstream/maingitpush origin main# 6. 创建功能分支并开发gitcheckout-bfeature/my-contribution# ... 开发 ...gitpush origin feature/my-contribution# 7. 在 GitHub 上创建 PR从你的 feature 分支到原始仓库的 main六、团队协作中的 .gitignore 策略6.1 项目级 .gitignore# 构建产物 dist/ build/ *.min.js *.min.css # 依赖 node_modules/ vendor/ .venv/ # 环境配置敏感信息 .env .env.local .env.*.local config/secrets.yml # 日志 *.log logs/ # IDE .idea/ .vscode/ *.swp # 操作系统 .DS_Store Thumbs.db6.2 团队共享的 .gitignore# 把 .gitignore 提交到仓库所有人共享gitadd.gitignoregitcommit-mchore: add .gitignore6.3 已跟踪文件添加到 .gitignore# 文件已经被 Git 跟踪了现在要忽略它gitrm--cachedfilegitcommit-mchore: ignore file七、团队分支保护规则7.1 GitLab 分支保护设置Settings → Repository → Protected Branches 推荐设置 ┌────────────────┬─────────────────────────────────────┐ │ 分支 │ 保护规则 │ ├────────────────┼─────────────────────────────────────┤ │ main │ 允许合并Maintainer │ │ │ 允许推送No one │ │ │ 允许强制推送No │ ├────────────────┼─────────────────────────────────────┤ │ develop │ 允许合并Maintainer │ │ │ 允许推送Maintainer │ │ │ 允许强制推送No │ ├────────────────┼─────────────────────────────────────┤ │ release/* │ 允许合并Maintainer │ │ │ 允许推送Maintainer │ └────────────────┴─────────────────────────────────────┘7.2 合并前必须满足的条件Settings → Merge requests → Merge checks 推荐设置 □ Pipelines must succeed ← CI/CD 测试必须通过 □ All discussions must be resolved ← 所有讨论必须解决 □ Approvals required: 1 ← 至少 1 人批准 □ Code owners must approve ← 代码负责人必须批准八、GitLab CI/CD 基础配置8.1 .gitlab-ci.yml 示例# 定义阶段stages:-test-build-deploy# 测试阶段unit-test:stage:testimage:node:18script:-npm install-npm run testonly:-merge_requests-main# 构建阶段build:stage:buildimage:node:18script:-npm install-npm run buildartifacts:paths:-dist/only:-main# 部署阶段deploy:stage:deployscript:-echo Deploying to production...# 实际部署脚本only:-mainwhen:manual# 手动触发部署九、团队协作礼仪9.1 Commit 礼仪✅ 提交前检查有没有调试代码 ✅ 一个 commit 做一件事 ✅ 写清楚的 commit message ✅ 提交前 pull 最新代码 ❌ 提交 console.log / print 调试语句 ❌ 把 IDE 配置文件提交上去 ❌ 一次提交 100 个文件没有意义9.2 MR 礼仪✅ 创建 MR 前自己先看一遍 diff ✅ 写清楚的描述 ✅ 及时响应 Review 评论 ✅ 讨论时对事不对人 ❌ 创建了 MR 就不管了 ❌ 一个人霸占一个大 MR 很久 ❌ Review 时只说 LGTMLook Good To Me9.3 Review 礼仪✅ 给出具体的改进建议 ✅ 解释为什么有问题 ✅ 区分 必须改 和 建议改 ✅ 肯定做得好的地方 ❌ 只挑毛病不表扬 ❌ 改动太大要求重新提交可以分 MR ❌ 不回复作者的讨论十、练习清单学完本章请完成以下操作在 GitLab 上创建一个 MR按照规范写好描述找同事互相 Review 一次 MR制造一次合并冲突并用 rebase 解决在 GitLab 上设置分支保护规则如果没有权限让 leader 帮你设置阅读一次别人写的.gitlab-ci.yml用git log --author查看你和同事的提交记录上一章03-Git工作流实战下一章05-企业级CI-CD与代码质量
git进阶05_团队协作与 Code Review
04 - 团队协作与 Code Review本章目标掌握团队协作开发的核心技能学会在 GitLab 上进行高质量的 Code Review。一、Pull Request / Merge Request 的本质PRGitHub 叫法/ MRGitLab 叫法不是请求合并代码而是一次技术评审的过程。开发者提交 MR │ ▼ CI/CD 自动跑测试 ← 必须通过 │ ▼ Code Review人工审核← 至少 1 人批准 │ ▼ 合并到目标分支 │ ▼ 自动部署如果有 CI/CD二、MR 的正确打开方式2.1 创建一个好的 MR# MR 标题和 commit message 一样要规范 feat(auth): implement user login with JWT # MR 描述模板 ## 改动说明 - 新增登录页面login.html - 实现 JWT 认证逻辑auth.service.js - 添加登录 API 接口/api/auth/login ## 关联 Issue - Closes #123 ## 测试说明 - 本地测试通过 - 添加了登录功能的单元测试 ## 截图如果是前端改动 [粘贴截图]2.2 MR 原则✅ 好的 MR - 一个 MR 只做一件事 - 代码量控制在 200-400 行以内 - 有清晰的描述和测试说明 - 关联了 Issue/Jira 编号 ❌ 不好的 MR - 把 5 个功能混在一个 MR 里 - 1000 行代码没有描述 - 没有关联任何 Issue2.3 GitLab MR 操作步骤1. 推送代码到你的分支 git push -u origin feature/user-login 2. 打开 GitLab进入项目 3. 点击 New Merge Request 4. 选择源分支和目标分支 5. 填写标题和描述 6. 指定审核人Reviewer 7. 点击 Create Merge Request三、Code Review 全流程3.1 作为 Reviewer审核别人的代码审核清单□ 功能完整性 - 代码是否实现了需求 - 边界条件是否处理 - 错误处理是否完善 □ 代码质量 - 命名是否清晰有意义 - 代码是否可读 - 是否有重复代码 - 函数是否过长 □ 安全性 - SQL 注入 - XSS 攻击 - 敏感信息是否硬编码 □ 性能 - 有没有明显的性能问题 - 数据库查询是否合理 □ 测试 - 是否有测试 - 测试覆盖是否足够 □ 规范 - 是否符合团队编码规范 - Commit message 是否规范3.2 如何给出好的 Review 评论# ❌ 不好的评论这代码有问题# ✅ 好的评论 这里有个潜在的空指针问题。当 user 为 null 时调用 user.getName()会抛异常。 建议 javaif(user!null){String nameuser.getName();//...}或者用 OptionalOptional.ofNullable(user).map(User::getName).ifPresent(name-{// ...});3.3 评论类型标签标签含义必须改吗nit/nits小问题建议但不强求否suggestion改进建议否issue/bug必须修复的问题是question需要解释的地方看情况四、解决 Merge 冲突团队协作最常见的痛点4.1 冲突产生原因main 分支 A — B — Cfeature 分支 D — E如果 C 和 E 修改了同一个文件的同一部分合并时就会冲突。4.2 解决冲突的标准流程# 方法一在本地解决 # 1. 保持你的分支最新gitcheckout feature/user-logingitfetch origingitrebase origin/main# 2. 如果有冲突Git 会暂停# CONFLICT (content): Merge conflict in src/login.js# Automatic rebase failed; fix up your branch and run git rebase again.# 3. 查看冲突文件gitstatus# both modified: src/login.js# 4. 编辑冲突文件# 文件中会有标记HEAD 你的代码别人的代码def5678# 5. 手动选择保留哪部分或合并两者# 6. 删除冲突标记 # 7. 标记冲突已解决gitaddsrc/login.js# 8. 继续 rebasegitrebase--continue# 9. 推送需要 force push因为历史被重写了gitpush --force-with-lease4.3 冲突解决技巧# 使用可视化工具解决冲突gitmergetool# 使用 VS Code 解决冲突推荐# VS Code 会高亮冲突点击 Accept Current / Accept Incoming / Accept Both# 放弃本次 rebase/mergegitrebase--abortgitmerge--abort4.4 减少冲突的最佳实践1. 频繁同步每天至少拉一次 main/develop 2. 小步提交MR 越小冲突概率越低 3. 及时合并MR 通过后尽快合并不要拖 4. 通信协调多人改同一文件时提前沟通五、Fork 工作流开源项目常见如果你在开源社区贡献代码通常没有直接 push 的权限需要 Fork。┌─────────────────────────────────────────────┐ │ 原始仓库upstream │ │ github.com/org/project │ └──────────────┬──────────────────────────────┘ │ ┌──────────┼──────────┐ │ │ │ ▼ ▼ ▼ Fork A Fork B Fork C 你的 别人的 别人的# 1. Fork 原始仓库到你的 GitHub# 2. 克隆你 Fork 的仓库gitclone gitgithub.com:your-name/project.gitcdproject# 3. 添加原始仓库为 upstreamgitremoteaddupstream gitgithub.com:org/project.git# 4. 查看远程仓库gitremote-v# origin gitgithub.com:your-name/project.git (fetch)# origin gitgithub.com:your-name/project.git (push)# upstream gitgithub.com:org/project.git (fetch)# upstream gitgithub.com:org/project.git (push)# 5. 同步 upstream 的最新代码gitfetch upstreamgitcheckout maingitmerge upstream/maingitpush origin main# 6. 创建功能分支并开发gitcheckout-bfeature/my-contribution# ... 开发 ...gitpush origin feature/my-contribution# 7. 在 GitHub 上创建 PR从你的 feature 分支到原始仓库的 main六、团队协作中的 .gitignore 策略6.1 项目级 .gitignore# 构建产物 dist/ build/ *.min.js *.min.css # 依赖 node_modules/ vendor/ .venv/ # 环境配置敏感信息 .env .env.local .env.*.local config/secrets.yml # 日志 *.log logs/ # IDE .idea/ .vscode/ *.swp # 操作系统 .DS_Store Thumbs.db6.2 团队共享的 .gitignore# 把 .gitignore 提交到仓库所有人共享gitadd.gitignoregitcommit-mchore: add .gitignore6.3 已跟踪文件添加到 .gitignore# 文件已经被 Git 跟踪了现在要忽略它gitrm--cachedfilegitcommit-mchore: ignore file七、团队分支保护规则7.1 GitLab 分支保护设置Settings → Repository → Protected Branches 推荐设置 ┌────────────────┬─────────────────────────────────────┐ │ 分支 │ 保护规则 │ ├────────────────┼─────────────────────────────────────┤ │ main │ 允许合并Maintainer │ │ │ 允许推送No one │ │ │ 允许强制推送No │ ├────────────────┼─────────────────────────────────────┤ │ develop │ 允许合并Maintainer │ │ │ 允许推送Maintainer │ │ │ 允许强制推送No │ ├────────────────┼─────────────────────────────────────┤ │ release/* │ 允许合并Maintainer │ │ │ 允许推送Maintainer │ └────────────────┴─────────────────────────────────────┘7.2 合并前必须满足的条件Settings → Merge requests → Merge checks 推荐设置 □ Pipelines must succeed ← CI/CD 测试必须通过 □ All discussions must be resolved ← 所有讨论必须解决 □ Approvals required: 1 ← 至少 1 人批准 □ Code owners must approve ← 代码负责人必须批准八、GitLab CI/CD 基础配置8.1 .gitlab-ci.yml 示例# 定义阶段stages:-test-build-deploy# 测试阶段unit-test:stage:testimage:node:18script:-npm install-npm run testonly:-merge_requests-main# 构建阶段build:stage:buildimage:node:18script:-npm install-npm run buildartifacts:paths:-dist/only:-main# 部署阶段deploy:stage:deployscript:-echo Deploying to production...# 实际部署脚本only:-mainwhen:manual# 手动触发部署九、团队协作礼仪9.1 Commit 礼仪✅ 提交前检查有没有调试代码 ✅ 一个 commit 做一件事 ✅ 写清楚的 commit message ✅ 提交前 pull 最新代码 ❌ 提交 console.log / print 调试语句 ❌ 把 IDE 配置文件提交上去 ❌ 一次提交 100 个文件没有意义9.2 MR 礼仪✅ 创建 MR 前自己先看一遍 diff ✅ 写清楚的描述 ✅ 及时响应 Review 评论 ✅ 讨论时对事不对人 ❌ 创建了 MR 就不管了 ❌ 一个人霸占一个大 MR 很久 ❌ Review 时只说 LGTMLook Good To Me9.3 Review 礼仪✅ 给出具体的改进建议 ✅ 解释为什么有问题 ✅ 区分 必须改 和 建议改 ✅ 肯定做得好的地方 ❌ 只挑毛病不表扬 ❌ 改动太大要求重新提交可以分 MR ❌ 不回复作者的讨论十、练习清单学完本章请完成以下操作在 GitLab 上创建一个 MR按照规范写好描述找同事互相 Review 一次 MR制造一次合并冲突并用 rebase 解决在 GitLab 上设置分支保护规则如果没有权限让 leader 帮你设置阅读一次别人写的.gitlab-ci.yml用git log --author查看你和同事的提交记录上一章03-Git工作流实战下一章05-企业级CI-CD与代码质量
