怎样用git做代码评审

用 Git 做代码评审（Code Review）常见有 “基于 Git 工作流的人工评审” 和 “借助平台工具（如 GitHub / GitLab / Gitee）” 两种方式。下面从基础概念 → 常用流程 → 实用命令 → 平台做法系统讲一下。

一、核心思想

代码评审的本质是：

在代码合并前，让别人 review 你的 Git 提交（commit / 分支 / PR）

Git 本身不提供“评审界面”，但提供了分支、diff、log等能力，配合平台即可完成评审。

二、最推荐的评审工作流（分支评审）

1️⃣ 基于功能分支开发

# 从主分支切出功能分支
git checkout main
git pull
git checkout -b feature/login

开发完成后：

git add .
git commit -m "feat: 实现登录功能"
git push origin feature/login

2️⃣ 发起评审（PR / MR）

• GitHub：Pull Request（PR）
• GitLab：Merge Request（MR）
• Gitee：Pull Request

评审内容包括：

• 代码 diff
• commit 历史
• CI 运行状态
• reviewer 评论

3️⃣ Reviewer 评审重点

• 逻辑是否正确
• 是否有边界情况
• 命名 / 结构是否清晰
• 是否引入风险
• 是否符合团队规范

4️⃣ 修改后再次提交

git commit --amend        # 修改最后一个 commit
# 或
git commit -m "fix: 根据评审意见修改"
git push -f               # 仅限个人分支

三、纯 Git 命令做“轻量评审”

如果没有平台，也可以本地评审：

查看差异

git diff main..feature/login

查看提交历史

git log main..feature/login

逐行评审（推荐）

git diff --word-diff

本地模拟评审

git checkout feature/login
git diff main

四、Commit 级别评审（更专业）

✅ 好的 commit 习惯

feat: 添加用户登录接口
fix: 修复 token 过期问题
refactor: 拆分 auth 模块

查看单个 commit

git show <commit-id>

交互式 review

git log -p

五、常见评审规范建议

分支规范

• feature/*：功能
• bugfix/*：修复
• hotfix/*：线上紧急

PR 规范

• 一个 PR 只做一件事
• 描述清楚：做了什么、为什么做
• 关联 issue / 需求

六、自动化辅助评审（推荐）

• ✅ CI 跑单测
• ✅ Lint 检查
• ✅ 覆盖率检测
• ✅ 禁止直接 push main

七、最小可行评审流程（MVP）

1. 切分支开发
2. 提交清晰 commit
3. 提 PR / MR
4. 至少 1 人 review
5. CI 通过
6. 合并

如果你愿意，我可以：

• 给你一套 Git 代码评审规范模板
• 教你 GitHub / GitLab 实际操作截图流程
• 帮你设计 团队 Git 工作流（小团队 / 大团队）

你现在是 个人项目还是团队项目？用 GitHub 还是 GitLab？