团队协作

这一课你将能做到

1. 解释为什么代码审查（Code Review）是技术成长最快的方式之一
2. 在团队冲突发生时，正确执行 git merge --abort 或 git rebase --abort 并寻求帮助
3. 理解维护者（Maintainer）、贡献者（Contributor）和审阅者（Reviewer）的职责边界

为什么要学

如果你认为 Git 只是一个文件历史管理工具，那你就错过了它真正的威力：团队协作与知识传承。一个优秀的开发者，不仅要能写出正确的代码，还要能看懂别人的代码，提出建设性的意见，并在分歧中找到共识。本课将带你走进真实的团队开发场景。

先建立图像

代码审查就像报纸的校对环节。记者写完文章（开发者写完代码），编辑（审阅者）会检查事实是否准确、文字是否通顺、排版是否美观。同样，代码审查会检查逻辑是否正确、是否符合规范、是否有潜在的安全隐患。没有经过审查的代码，就像没有校对过的报纸，错误百出。

开发者完成代码 → 创建 Pull Request → 自动触发 CI 测试 → 审阅者检查代码 → 
通过审查 → 合并到主分支

跟着做

步骤 1：扮演审阅者（Reviewer）

假设你的同事提交了一个 Pull Request，请求合并一个用户登录功能。

首先，你需要通读整个 PR 的改动：

1. 打开 PR 页面，阅读标题和描述，理解其改动意图。
2. 切换到 "Files changed" 标签页，逐行阅读代码。
3. 当你看到不理解的地方，点击行号旁边的 "+" 号，添加评论：
   • "这里的变量名 x 是什么意思？能否改为更具描述性的名称，例如 userLoginCount？"
   • "这个函数没有处理空指针异常，是否应该增加 try-catch 块？"
4. 阅读完毕后，点击右上角的 "Review changes" 按钮，选择 "Request changes"。

步骤 2：处理审查意见（作为开发者）

你收到了审阅者的反馈，不要急着反驳，先深呼吸，然后：

1. 逐条确认：对于每一条评论，思考其合理性。
2. 修改代码：在本地根据意见修改代码。
3. 回复评论：在 PR 页面对应的评论下回复，例如 "已修改，将变量名改为 userLoginCount" 或 "这是一个好建议，已添加空指针检查"。
4. 重新提交：修改完成后，将新的提交推送到同一个远程分支。PR 会自动更新。

# 在本地修改代码
git add .
git commit -m "refactor: 根据审查意见优化变量命名和异常处理"
git push origin feature/login

步骤 3：解决合并冲突（Merge Conflict）

假设你的 PR 在等待审查期间，主分支 main 被其他人合并了新的代码，导致你的分支与 main 产生了冲突。

1. 同步远程主分支：

   git switch main
   git pull origin main
   

2. 切换回你的功能分支并合并主分支：

   git switch feature/login
   git merge main
   

3. Git 会提示哪些文件存在冲突。打开这些文件，你会看到类似下面的标记：

   <<<<<<< HEAD
       int userCount = 0;
   =======
       int totalUsers = 10;
   >>>>>>> main
   

4. ，保留你需要的代码，并删除所有 , , 标记。